Net framework 5, а также среды Visual Studio 2012 и C#

Глава.23 .Загрузка.сборок.и.отражение
Метод 
ReflectionOnlyLoadFrom
загружает указанный файл, не получая ин-
формацию строгого имени сборки и не выполняя поиск файла в GAC или где-либо 
еще. Метод 
ReflectionOnlyLoad
выполняет поиск указанной сборки в GAC, ба-
зовом каталоге приложения, частных каталогах и каталоге, указанном в элементе 
codeBase
. Однако в отличие от 
Load
этот метод не применяет политику версий, 
поэтому не предоставляет гарантий, что будет загружена именно та сборка, которая 
ожидалась. Если вы хотите самостоятельно применить политику версий к сборке, 
можно передать строку с идентификационной информацией в метод 
AppDomain
класса 
ApplyPolicy
.
При загрузке сборок методом 
ReflectionOnlyLoadFrom
или 
ReflectionOnlyLoad
среда CLR запрещает выполнение какого-либо кода сборки, а при попытке вы-
полнить код генерирует исключение 
InvalidOperationException
. Эти методы 
позволяют инструменту загружать сборки с отложенным подписанием, сборки 
для процессора другой архитектуры, а также сборки, для загрузки которых нужны 
особые разрешения.
Часто при использовании отражения для анализа сборки, загруженной одним 
из указанных двух методов, код должен зарегистрировать метод обратного вызова 
на событие 
ReflectionOnlyAssemblyResolve
класса 
AppDomain
, чтобы вручную за-
гружать произвольные сборки, задаваемые клиентом (при необходимости вызывая 
метод 
ApplyPolicy
класса 
AppDomain
); CLR не делает этого автоматически. Будучи 
вызванным, метод обратного вызова должен вызвать метод 
ReflectionOnlyLoadFrom
или 
ReflectionOnlyLoad
класса 
Assembly
, чтобы явно загрузить указанную сборку 
и вернуть ссылку на нее.
ПриМеЧание
Меня.часто.спрашивают.о.порядке.выгрузки.сборок .К.сожалению,.CLR.не.позволяет.
выгружать.отдельные.сборки .Если.бы.это.было.так,.возможна.была.бы.ситуация,.когда.
поток.возвращает.управление.из.метода.в.код.выгруженной.сборки,.и.в.результате.
происходит.сбой.приложения .Однако.среда.CLR.предназначена.в.первую.очередь.
на.повышение.надежности.и.безопасности,.а.подобные.сбои.явно.противоречат.
этим.целям .Чтобы.выгрузить.сборку,.придется.выгрузить.весь.домен.приложений,.
в.котором.она.находится .Подробнее.см .главу.22 
Казалось. бы,. сборки,. загруженные. методом. ReflectionOnlyLoadFrom. или.
ReflectionOnlyLoad,.должно.быть.разрешено.выгрузить .В.конце.концов,.ведь.код.
этих.сборок.нельзя.выполнять .Однако.CLR.не.разрешает.выгрузку.сборок,.загру-
женных.одним.из.этих.методов,.по.той.простой.причине,.что.после.загрузки.сборок.
вы.всегда.сможете.использовать.отражение.для.создания.объектов,.ссылающихся.
на.метаданные,.определенные.в.этих.сборках .При.выгрузке.сборки.потребовалось.
бы.каким-то.образом.сделать.объекты.недействительными,.но.отслеживание.всех.
этих.связей.—.слишком.сложная.и.ресурсоемкая.задача 
Многие приложения содержат EXE-файлы, зависимые от многих DLL-файлов. 
При установке этих приложений также должны устанавливаться все файлы. Од-
нако обычно практикуется установка единственного EXE-файла. В этом случае 

---

641
Использование.отражения.для.создания.динамически.расширяемых.приложений
в первую очередь идентифицируйте все DLL-файлы, от которых зависит ваш 
EXE-файл и которые не являются частью платформы Microsoft .NET Framework. 
Затем добавьте эти DLL-файлы к вашему проекту в Visual Studio и для каждого 
добавленного DLL-файла откройте окно свойств и измените значение 
Build
Action
на 
Embedded
Resource
. Это действие даст указание компилятору C# добавить DLL-
файлы в EXE-файл, который в конечном итоге и будет устанавливаться.
На этапе выполнения программы среда CLR не сможет найти зависимые сборки, 
что может вызвать проблемы. Для решения этих проблем зарегистрируйте методы 
обратного вызова при помощи события 
ResolveAssembly
при инициализации вашего 
приложения. Программный код должен выглядеть примерно так:
private static Assembly ResolveEventHandler(Object sender, ResolveEventArgs args) { 
String dllName = new AssemblyName(args.Name).Name + ".dll"; 
var assem = Assembly.GetExecutingAssembly(); 
String resourceName = assem.GetManifestResourceNames().FirstOrDefault(rn => 
rn.EndsWith(dllName)); 
if (resourceName == null) return null;
// Not found, maybe another handler will find it 
using (var stream = assem.GetManifestResourceStream(resourceName)) { 
Byte[] assemblyData = new Byte[stream.Length]; 
stream.Read(assemblyData, 0, assemblyData.Length); 
return Assembly.Load(assemblyData); 
} 
}
При первом вызове в потоке метода, ссылающегося на тип, зависящий от 
DLL-файла, возникнет событие 
AssemblyResolve
, и показанный программный 
код обратного вызова найдет встроенный DLL-файл и загрузит его путем вызова 
перегруженного метода 
Load
, у которого в качестве аргумента будет использоваться 
Byte[]
. И хотя мне нравится прием встраивания зависимых DLL в другие сборки, 
следует помнить, что он увеличивает объем памяти, используемой приложением 
во время выполнения.