Меня недавно спросили, знаю ли я что-нибудь о динамических сборках в .Net. Короткий ответ был - нет.
Я нашел множество статей, в которых описывается, как создать динамическую сборку, но ни одна из них не объясняет следующее:
Будем очень признательны за любые пояснения к вышеизложенному.
Большое спасибо.
Эта статья немного устарела, и код немного простоват, но я бы сказал, что это одна из самых доступных статей, касающихся динамической компиляции и некоторых важных проблем.
Здесь я научился компилировать сборки на лету, как в памяти, когда мне не нужно было выгружать или контролировать безопасность, так и во временный файл, который нужно загрузить с удаленным взаимодействием, чтобы разрешить выгрузку.
Пример из реальной жизни: онлайн-инструмент для регулярных выражений .net, который принимает код C # для метода замены, который динамически компилируется в изолированную сборку, используется для выполнения замены и отбрасывается. Эта стратегия работала отлично, но вероятность внедрения вредоносного кода вне зависимости от изолированной программной среды была слишком велика, поэтому в конечном итоге от этой идеи отказались.
Удачи.
Приведу несколько примеров:
ASPNET создает сборки и загружает их динамически для каждого ASPX, ASMX или ASHX. Настоящее преимущество здесь в том, что код приложения может быть развернут на языке шаблонов и может динамически компилироваться и запускаться по запросу. Динамическая часть обеспечивает очень простую и удобную модель развертывания, а также означает эффективность: фактически загружаются только вызываемые страницы.
DotNetZip создает динамическую сборку при сохранении самораспаковывающегося архива. На самом деле он не «запускается из памяти», он в конечном итоге записывается в файл, так что это может или не может соответствовать вашему определению для динамической сборки. Сборка создается динамически во время выполнения. Но в данный момент он не задействован. Зачем создавать его динамически? Поскольку исполняемый файл должен иметь возможность использовать определенный значок Win32, ему может потребоваться номер версии и другие свойства. Эти параметры можно установить во время компиляции. Кроме того, исходный код сборки является производным от шаблона с использованием различных данных, предоставленных вызывающей стороной, для заполнения слотов в шаблоне. Так что динамически сгенерированная сборка - действительно правильный путь.
В платформе веб-служб ASMX .NET компилятор wsdl.exe (или инструмент xsd.exe) будет создавать типы для сериализации / десериализации XML-сообщений. Обычно он генерирует типы, в которых элементы XML смоделированы как общедоступные поля. Но хотя DataGrid и другие элементы управления с привязкой к данным могут использовать массивы объектов в качестве источников данных, они отображают только общедоступные свойства. Поэтому приложение не могло выполнить вызов веб-служб, получить обратно массив объектов, а затем назначить его в качестве источника для Datagrid. Я использовал динамически сгенерированную сборку в качестве адаптера, чтобы элементы управления, управляемые данными, могли использовать выходные данные вызовов веб-служб. [Думаю, эта проблема исчезла с помощью ObjectDataSource и других изменений в .NET].
Внутри .NET создание экземпляра класса System.Xml.Serialization.XmlSerializer для определенного типа создает динамическую сборку. Я полагаю, что выигрыш здесь такой же, как и в случае любого сравнения скомпилированного кода с интерполяцией. в сериализации xml основная идея состоит в том, чтобы перечислить через общедоступные поля и свойства типа, а затем создать XML-документ, содержащий значения из этих полей и свойств. Было бы неплохо, если бы приложению не приходилось использовать System.Reflection для перечисления членов типа (очень медленно) при каждом вызове XmlSerializer.Serialize ()?
Вот недавний вопрос SO, описывающий сценарий, в котором кто-то хочет создать динамическую сборку:
Как использовать генерацию кода для динамического создания методов C #?
