Нет AppDomains в .NET Core! Зачем?

Есть ли веская причина, почему Microsoft предпочла не поддерживать AppDomains в .NET Core?

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

Без AppDomains, как мы собираемся заменить наши сборки в длительном серверном процессе?

AppDomains также предоставляют нам способ изолировать различные части кода сервера. Например, пользовательский сервер websocket может иметь код сокета в основном приложении, в то время как наши службы работают во вторичном домене.

Без AppDomains приведенный выше сценарий невозможен.

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

Ответ 1

Точкой подмножества .NETCore должно было быть установлено .NET install small. И легко переносить. Вот почему вы можете, скажем, запустить приложение Silverlight как на Windows, так и на OSX и не ждать очень долго, когда вы посещаете веб-страницу. Загрузка и установка полного времени выполнения и структуры занимает несколько секунд, давая или беря.

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

Ответ 2

Обновление для .NET Standard 2 и .NET Core 2

В .NET Standard 2 существует класс AppDomain. Однако многие части этого API будут бросать PlatformNotSupportedException для .NET Core.

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

В стандартном стандарте .NET это объяснение:

Является частью AppDomain стандарта .NET?

Тип AppDomain является частью .NET Standard. Не все платформы будут поддерживать создание новых доменов приложений, например .NET Core не будет, поэтому метод AppDomain.CreateDomain, будучи доступным в .NET Standard, может вызывать PlatformNotSupportedException.

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

Кроме того, лучший ответ и другие ответы также приятно объясняют, почему основная часть AppDomain все еще была отключена (например, выбрасывает исключение, не поддерживаемое).

Ответ 3

В какой-то момент я слышал, что разгрузочные сборки будут включены без использования доменов. Я думаю, что тип System.Runtime.Loader.AssemblyLoadContext в System.Runtime.Loader.dll связан с этой работой, но я не вижу там ничего, что позволяет разгрузить еще.

Ответ 4

Домены приложений

Почему это было прекращено? AppDomains требует поддержки во время выполнения и, как правило, довольно дорого. Хотя он по-прежнему реализуется CoreCLR, его недоступно в .NET Native, и мы не планируем добавлять туда эту возможность.

Что следует использовать вместо этого? AppDomains использовались для разных целей. Для изоляции кода мы рекомендуем обрабатывать и/или контейнеры. Для динамической загрузки сборок мы рекомендуем новый класс AssemblyLoadContext.

Источник из блога

Ответ 5

Я слышал в сообществе standup или некоторых разговорах о том, что функция изоляции AppDomains лучше обрабатывается процессами (и на самом деле общим шаблоном на других платформах), и разгрузка действительно запланирована как нормальная функция, не связанная с AppDomains.