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