Я не понимаю домены приложений

Question

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

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

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

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

Answer 1

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

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

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

Сложно сказать «да» или «нет» тому, уважает ли поток домен приложения. Один поток может находиться в N разных доменах приложений. Такая ситуация возможна, если объект в одном домене приложений выполняет удаленный вызов объекта в другом домене приложений. Для завершения потока потребуется выполнить переход между доменами приложений.

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

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

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

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

Answer 2

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

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

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

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

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

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

Answer 3

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

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

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