Есть кое-что, что я хочу настроить в System.Web.Script.Services.ScriptHandlerFactory и других материалах .NET внутри внутреннего класса. К сожалению, это внутренний класс. Какие варианты у меня есть при попытке настроить метод в этом классе?





Вы можете найти эта недавняя статья поучительным. По сути, он говорит, что вы не можете переопределить что-либо с маркировкой internal, и источник примерно настолько авторитетен, насколько это возможно. Лучшее, на что вы можете надеяться, - это метод расширения.
Блог Эрика Липперта - отличный ресурс, я следил за ним годами.
Ключевое слово internal означает, что модуль кода (класс, метод и т. д.) Является «общедоступным» для сборки, в которой он находится, но частным для любой другой сборки.
Поскольку вы находитесь в разных сборках, вы ничего не можете сделать. Если бы он не был внутренним, вы могли бы использовать ключевое слово new в методе, который вы переопределяете (чтобы скрыть исходную реализацию) при расширении класса.
Вкратце: вы должны быть СОЛОМ.
Единственное, что я могу придумать, что вы могли бы сделать, это написать прокси-класс, где одно из ваших частных полей - это класс, который вы хотите расширить, и вы реализуете все его методы и проксируете их вызовы. таким образом вы все еще можете настроить вывод, но вам придется использовать свой класс, и, учитывая, что он помечен как внутренний, я не уверен, что это возможно без серьезного взлома.
using System;
...
using System.Web.Script.Services
namespace MyGreatCompany.ScriptServices
{
public class MyScriptHandlerFactory /* implement all the interfaces */
{
private ScriptHandlerFactory internalFactory;
public MyScriptHandlerFactory()
{
internalFactory = new ScriptHandlerFactory();
}
...
}
}
Этот мог делает то, что вы хотите достичь, возможным, но это будет некрасиво.
Я считаю, что вы можете использовать Reflection, чтобы обойти модификаторы доступа в классе, поэтому, возможно, вы можете использовать Reflection.Emit для создания типа, который наследуется от внутреннего типа (но НЕТ - модификатор sealed), хотя я не могу найти пример об этом в Интернете.
Это определенно работает для доступа к закрытым членам классов и, возможно, для наследования незапечатанных классов. Но это не очень помогает, если целевые методы еще не отмечены как виртуальные.
Это также, вероятно, работает только тогда, когда вы работаете с полным доверием. Любой контекст, требующий проверки, потерпит неудачу, если вы нарушите контроль доступа.
Этот подход также не работает, за исключением типа System.TypeLoadException: метод MyOverridingMethod для типа MyClass из сборки MyAssembly, Version = 0.0.0.0, Culture = нейтральный, PublicKeyToken = null переопределяет метод, который является не видно из этой сборки.
Это зависит от сборки. Это может привести к некоторому нарушению лицензирования (хотя это похоже на своего рода статическое связывание) и, возможно, даже превратить развертывание в кошмар, но вы можете подумать:
Вы действительно не должны этого делать, так как владелец класса пометил его как внутренний (читайте ... не расширяйте, так как я могу изменить его позже / Работа в процессе / еще не лучший вариант). Создайте свою собственную копию класса и используйте ее, если действительно необходимо.