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

ВниМание
На.одной.машине.могут.находиться.разные.сборки.с.одинаковой.идентификационной.
информацией .Так.как.LoadFrom.вызывает.Load,.может.оказаться,.что.CLR.загрузит.не.
указанный,.а.другой.файл,.что.чревато.непредсказуемым.поведением .Настоятель-
но.рекомендуется.при.каждой.компоновке.сборки.изменять.номер.редакции.—.так.
обеспечивается.строгая.индивидуальность.идентификационной.информации.всех.
сборок,.а.значит,.вызов.метода.LoadFrom.не.принесет.неожиданностей 
Конструкторы графического интерфейса и другие инструменты Microsoft Visual 
Studio обычно используют метод 
LoadFile
класса 
Assembly
. Этот метод может 
загрузить сборку по любому пути и его можно задействовать для загрузки сборки 
с идентичными параметрами в единственный домен приложений. Это удобно 
в случае, когда при помощи конструктора или другого инструмента были внесены 
изменения в графический интерфейс приложения, а затем это приложение было 
собрано заново. При загрузке 
LoadFile
среда CLR не разрешает зависимости авто-
матически, поэтому ваш программный код должен быть зарегистрирован в событиях 
AssemblyResolve
и иметь явно загруженные методы обратных вызовов событий 
всех зависимых сборок.
Если вы создаете инструмент, который просто анализирует метаданные сборки 
с использованием отражения (об этом — чуть позже), не выполняя никакого кода сбор-
ки, лучше всего для загрузки сборки задействовать метод 
ReflectionOnlyLoadFrom
или, в некоторых редких случаях, метод 
ReflectionOnlyLoad
класса 
Assembly
. Вот 
прототипы обоих методов:
public class Assembly {
public static Assembly ReflectionOnlyLoadFrom(String assemblyFile);
public static Assembly ReflectionOnlyLoad(String assemblyString);
// Менее популярные перегруженные версии не показаны
}

---

640