Я не розумію Домени додатків

.NET має таку концепцію доменів додатків, які, наскільки я розумію, можуть бути використані для завантаження збірки в пам’ять. Я провів деякі дослідження доменів додатків, а також завітав до мого місцевого книжкового магазину, щоб отримати додаткові знання з цього питання, але це здається дуже мізерним.

Все, що я можу зробити з доменами додатків, - це завантажувати збірки в пам’ять, і я можу їх вивантажувати, коли захочу.

Які ще можливості я згадав про Домени додатків? Чи нитки поважають межі доменів додатків? Чи є якісь недоліки від завантаження Асамблей в різні домени додатків, крім основних доменів додатків, окрім продуктивності зв'язку?

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

AppDomains найкраще візуалізувати як дуже легкий процес.

У процесі. Net може бути N додаткових доменів, але загалом кажучи, існує лише один. Справжньою перевагою AppDomains є те, що вони забезпечують межу ізоляції у вашому процесі. Об'єкти можуть розмовляти між собою лише через межу AppDomain за допомогою віддалення або серіалізації.

Також можливо запустити 2 AppDomains на абсолютно різних рівнях безпеки в процесі. Це може дозволити вам запустити свою основну програму в Full Trust під час запуску ненадійних плагінів на набагато нижчому рівні довіри.

Важко просто сказати «так» чи «ні», чи поважає нитка AppDomain. Можливо, щоб один потік був у N різних AppDomains. Така ситуація можлива, якщо об’єкт в одному AppDomain робить віддалений виклик об’єкту в іншому AppDomain. Потік повинен буде перейти між AppDomains для завершення.

Недоліком AppDomains є головним чином складність. Віддалення може зайняти трохи часу, щоб розкрутити голову, і правильне налаштування AppDomain може бути нетривіальним процесом.

Можливо, ви захочете зазирнути до документації MSDN щодо AppDomains. Важко знайти підручник, який описує їх, оскільки вони мають різноманітні складні функції. Це забезпечує приємний огляд, який, якщо він не відповість прямо на ваше запитання, принаймні скерує вас у потрібне місце.

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

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

Відповідь ДжаредПара хороша, за винятком того, що він не відзначає причини існування для AppDomains - це означає, що ви можете РАЗГРУЗИТИ асамблею, розвантаживши її AppDomain. Якщо у вас тривалий процес ОС, і ви очікуєте, що доведеться завантажувати, а потім вивантажувати збірки з будь-якої причини, тоді вам потрібен AppDomain. Прикладом прототипу тут є ASP.NET, який завантажує збірки коду програм на вимогу, а потім може вивантажити їх пізніше, коли програми більше не використовуються активно.

Вартість, яку ви платите за можливість розвантаження, полягає в цій незалежності - вам потрібно спілкуватися через межу AppDomain. Не вдається здійснити простий виклик методу. Вам потрібно керувати життєвим циклом AppDomain. І т.д.

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

Існують випадкові сценарії. Мовляв, припустимо, ви хочете завантажити одночасно 2 різні версії збірки. Ви можете натрапити на підводні камені, якщо не розділити їх на AppDomains. Але це буде досить рідко.

Основним сценарієм, який виправдовує існування AppDomains, є тривалий процес, який повинен мати можливість розвантажувати збірки.

Звичайно, програми можуть покладатися на процес ОС, коли ви хочете вивантажити збірку. Іншими словами, у вас може бути запущено 3 або 4 взаємодіючих процеси, кожна з яких має свій власний набір збірок, і коли ви хочете вивантажити збірку, просто вимкніть процес, що розміщує цю збірку. Але AppDomain пропонує більш ефективний механізм для цього, не вимагаючи зупинки / запуску або перехресного обміну повідомленнями, що все ще важче, ніж перехресне сполучення AppDomain, описане раніше. Я маю на увазі, що це все ще віддалено, але це повільніше і перемикання контексту.

Деякі речі, які ви можете робити з AppDomains:

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

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