Я не понимаю Области приложений

У .NET есть эта концепция доменов приложений, которые, как я понимаю, могут использоваться для загрузки сборки в память. Я провел некоторое исследование по областям приложений, а также зашел в свой локальный книжный магазин за некоторыми дополнительными знаниями по этому предмету, но это кажется очень скудным.

Все, что я знаю, что я могу делать с областями приложений, - это загрузка сборок в памяти, и я могу их выгрузить, когда захочу.

Каковы возможности, которые я упомянул в областях приложений? Должны ли темы уважать границы доменов приложений? Существуют ли какие-либо недостатки при загрузке сборок в разных доменах приложений, отличных от основных доменов приложений, помимо производительности связи?

Ссылки на ресурсы, которые обсуждают Области приложений, также будут приятными. Я уже проверил MSDN, у которого не так много информации о них.

Ответ 1

AppDomains лучше всего визуализируется как очень легкий процесс.

Может быть N AppDomains для .Net-процесса, но, вообще говоря, есть только один. Реальное преимущество AppDomains заключается в том, что они обеспечивают границу изоляции внутри вашего процесса. Объекты могут разговаривать только друг с другом через границу AppDomain посредством удаленного или сериализации.

Также возможно запустить 2 AppDomains на совершенно разных уровнях безопасности в процессе. Это может позволить вам запустить основное приложение в режиме полного доверия при запуске Untrusted Plugins на гораздо более низком уровне доверия.

Неплохо сказать "да" или "нет", соответствует ли нить AppDomain или нет. Возможно, что один поток будет в N разных AppDomains. Такая ситуация возможна, если объект в одном AppDomain делает удаленный вызов объекта в другом AppDomain. Поток должен будет перейти между AppDomains для завершения.

Недостатком AppDomains является в основном сложность. Устранение может занять немного времени, чтобы окунуться в голову, и правильная настройка AppDomain может быть нетривиальным процессом.

Возможно, вы захотите заглянуть в документацию MSDN на AppDomains. Трудно найти учебник succint, который описывает их, потому что у них есть множество сложных функций. Это дает хороший обзор, который, если он не отвечает на ваш вопрос напрямую, по крайней мере укажет вас в нужное место.

http://msdn.microsoft.com/en-us/library/cxk374d9.aspx

Этот документ больше не поддерживается, обратитесь к нему за обновленной версией: https://msdn.microsoft.com/en-us/library/2bh4z9hs(v=vs.110).aspx

Ответ 2

Ответ JaredPar хорош, за исключением того, что он не отмечает raison d'etre для AppDomains - это то, что вы можете только РАЗГРУЗИТЬ Собрание путем разгрузки его AppDomain. Если вы долгое время выполняете ОС и ожидаете загрузки, а затем выгружаете сборки по какой-либо причине, то вам нужен AppDomain. Прототипным примером здесь является ASP.NET, который загружает сборки кода приложения по требованию, а затем может их выгружать позже, когда приложения больше не активно используются.

Стоимость, которую вы платите за возможность выгрузки, заключается в том, что независимость - вам нужно обмениваться данными через границу AppDomain, не удается выполнить простой вызов метода. Вам необходимо управлять жизненным циклом AppDomain. И т.д.

Если вам просто нужно динамически загружать сборки и не думайте, что вам нужно будет выгрузить их в течение одного процесса, вам, вероятно, не нужно будет запускать несколько приложений AppDomains. Хорошим примером здесь может быть богатое приложение, поддерживающее модель подключаемого модуля, где он вынюхивает сборки плагинов в каталоге "etc" и загружает их все. Однако, если подключаемая модель требует разгрузки плагинов... ну.

Есть более сложные сценарии. Например, предположим, что вы хотите одновременно загрузить две разные версии сборки. Вы можете столкнуться с ловушками, если вы не разделите их с AppDomains. Но это будет довольно редко.

Основной сценарий, который оправдывает существование AppDomains, - это длительный процесс, который должен иметь возможность разгружать сборки.

Конечно, приложения могут полагаться на процесс ОС, когда вы хотите выгрузить сборку. Другими словами, у вас может быть 3 или 4 взаимодействующих процесса, каждый из которых имеет свой собственный набор сборок, а когда вы хотите выгрузить сборку, просто закройте процесс, на котором размещена эта сборка. Но AppDomain предлагает механизм более высокого уровня для этого, не требуя перехвата/запуска процесса или перекрестного компромисса, который еще тяжелее, чем перекрестные ссылки AppDomain, описанные ранее. Я имею в виду, что он все еще удален, но он медленнее и больше переключений контекста.

Ответ 3

Некоторые вещи, которые вы можете делать с AppDomains:

вы можете отключить его, не ставя под угрозу стабильность вашей программы.
Вы можете загружать код и предоставлять ему меньше привилегий, чем ваш собственный процесс (например, ваш процесс работает полностью доверенным, но вы загружаете код в отдельный AppDomain, который даже не может создать файл на диске.)
Вы можете обрабатывать необработанные исключения из AppDomain без сбоя процесса.
Etc.

Проще говоря, это граница безопасности и крайняя граница процесса. Что касается производительности, то несколько приложений AppDomains в процессе не представляют значительных накладных расходов. Запуск отдельного процесса вместо AppDomain намного дороже.