Подтвердить что ты не робот

Разница между AppDomain.GetAssemblies и BuildManager.GetReferencedAssemblies

Просто хотелось узнать, есть ли разница между ними в контексте полностью доверенного приложения asp.net mvc 2.

4b9b3361

Ответ 1

.NET Framework откладывает загрузку сборок в текущий AppDomain до тех пор, пока они не понадобятся. Например, если вы звоните в стороннюю библиотеку только из SomeMethod(), то сторонняя DLL обычно не будет загружаться до первого запуска SomeMethod().

AppDomain.GetAssemblies() предоставляет вам все сборки, которые уже были загружены в текущий AppDomain. BuildManager.GetReferencedAssemblies() возвращает список всех сборок, ссылающихся на Web.config и в других местах, и загружает эти сборки в текущий AppDomain.

Вот выработанный пример выше.

  • SomeMethod() еще не запущен.
  • Вызвать AppDomain.GetAssemblies(), возвращает набор, который не включает файл ThirdParty.dll.
  • Вызов SomeMethod().
  • Вызвать AppDomain.GetAssemblies(), возвращает набор, содержащий ThirdParty.dll.

В этом примере CLR откладывает загрузку ThirdParty.dll в текущий AppDomain, пока это не станет абсолютно необходимым. И так как это необходимо для выполнения SomeMethod(), что при загрузке.

В качестве альтернативы:

  • SomeMethod() еще не запущен.
  • Вызвать AppDomain.GetAssemblies(), возвращает набор, который не включает файл ThirdParty.dll.
  • Вызов BuildManager.GetReferencedAssemblies(), возвращает набор, содержащий ThirdParty.dll.
  • Вызвать AppDomain.GetAssemblies(), возвращает набор, содержащий ThirdParty.dll.

Здесь, хотя вы никогда не вызывали SomeMethod(), вызов BuildManager.GetReferencedAssemblies() загружал стороннюю библиотеку в текущий AppDomain от вашего имени.

Конечно, все это зависит от определенных оптимизаций и т.д., но общая идея имеет место.