Размещение ASP.NET Core в Windows со службами IIS

Службы IIS — это гибкий, безопасный и управляемый веб-сервер для размещения веб-приложений, включая ASP.NET Core.

Поддерживаемые платформы

Поддерживаются следующие операционные системы:

• Windows 7 или более поздней версии.
• Windows Server 2012 R2 и более поздние версии

Поддерживаются приложения, опубликованные для развертывания в 32-разрядных (x86) или 64-разрядных (x64) системах. Развертывайте 32-разрядную версию (x86) приложения с использованием 32-разрядного пакета SDK для .NET Core, кроме следующих случаев:

• Приложению требуется более широкое адресное пространство виртуальной памяти, доступное в 64-разрядной версии приложения.
• Приложению требуется стек IIS большего размера.
• В коде присутствуют зависимости 64-разрядной версии.

Установка модуля или пакета размещения .NET Core

Скачайте последнюю версию установщика, используя следующую ссылку:

Текущий установщик пакета размещения .NET Core (прямая загрузка)

Подробные инструкции по установке модуля ASP.NET Core и по установке других версий см. в разделе Установка пакета размещения .NET Core.

Чтобы скачать предыдущие версии пакета размещения, ознакомьтесь с этой проблемой GitHub.

Начало работы

Сведения о том, как приступить к размещению веб-сайта на IIS, см. в нашем руководстве по началу работы.

Сведения о том, как приступить к размещению веб-сайта в службах приложений Azure, см. в нашем руководстве по развертыванию в Службе приложений Azure.

Настройка

Инструкции по настройке см. в статье Расширенная конфигурация.

Ресурсы развертывания для администраторов IIS

• Документация по службам IIS
• Начало работы с диспетчером IIS в IIS
• Развертывание приложений .NET Core
• модуль ASP.NET Core (ANCM) для IIS
• структура каталогов ASP.NET Core
• Модули IIS с ASP.NET Core
• Устранение неполадок ASP.NET Core в службе приложение Azure и IIS
• Устранение распространенных неполадок в Службе приложений Azure и службах IIS с помощью ASP.NET Core

Перезапуск с перекрытием

Как правило, мы рекомендуем использовать шаблон сине-зеленого развертывания для исключения простоев. Такие функции, как перезапуск с перекрытием, тоже можно использовать для этой цели, но в этом случае развертывание без простоев не гарантируется. Дополнительные сведения см. здесь на GitHub.

Необязательные сертификаты клиентов

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

Дополнительные ресурсы

• Устранение неполадок и отладка проектов ASP.NET Core
• Общие сведения об ASP.NET Core
• Официальный веб-сайт Microsoft IIS
• Библиотека технического содержимого по Windows Server
• HTTP/2 on IIS (HTTP/2 в IIS)
• Преобразование web.config

Руководство по публикации приложения ASP.NET Core на сервере IIS см. здесь: Публикация приложения ASP.NET Core в службах IIS.

Установка пакета размещения .NET Core

Поддерживаемые операционные системы

Поддерживаются следующие операционные системы:

• Windows 7 или более поздней версии.
• Windows Server 2012 R2 и более поздние версии

Сервер HTTP.sys (ранее назывался WebListener) не работает в конфигурации обратного прокси-сервера со службами IIS. Используйте Kestrelсервер.

Дополнительные сведения о размещении в Azure см. в статье Развертывание приложений ASP.NET Core в Службе приложений Azure.

Рекомендации по устранению неполадок см. в статье Устранение неполадок и отладка проектов ASP.NET Core.

Поддерживаемые платформы

Поддерживаются приложения, опубликованные для развертывания в 32-разрядных (x86) или 64-разрядных (x64) системах. Развертывайте 32-разрядную версию (x86) приложения с использованием 32-разрядного пакета SDK для .NET Core, кроме следующих случаев:

• Приложению требуется более широкое адресное пространство виртуальной памяти, доступное в 64-разрядной версии приложения.
• Приложению требуется стек IIS большего размера.
• В коде присутствуют зависимости 64-разрядной версии.

Для приложений, опубликованных для 32-разрядной архитектуры (x86), необходимо включить поддержку этой архитектуры для пулов приложений IIS. Дополнительные сведения см. в разделе Создание сайта IIS.

Используйте 64-разрядный (x64) пакет SDK для .NET Core для публикации 64-разрядной версии приложения. Для этого в системе узла должна присутствовать 64-разрядная версия среды выполнения.

Модели размещения

Модель внутрипроцессного размещения

При внутрипроцессном размещении приложение ASP.NET Core выполняется в том же процессе, что и рабочий процесс IIS. При этом повышается производительность по сравнению с внепроцессным размещением, так как запросы не передаются через адаптер замыкания на себя (сетевой интерфейс, который возвращает исходящий сетевой трафик на тот же компьютер). IIS обрабатывает управление процессом с помощью службы активации процессов Windows (WAS).

Модуль ASP.NET Core:

• Инициализирует приложение.
  • Загружает CoreCLR.
  • Вызывает Program.Main.
• Управляет жизненным циклом собственного запроса IIS.

На следующей схеме показана связь между IIS, модулем ASP.NET Core и приложением, размещенным внутри процесса.

1. Запрос поступает из Интернета в драйвер HTTP.sys в режиме ядра.
2. Драйвер направляет собственный запрос к IIS на настроенный порт веб-сайта — обычно 80 (HTTP) или 443 (HTTPS).
3. Модуль ASP.NET Core получает собственный запрос и передает его на HTTP-сервер IIS (IISHttpServer). HTTP-сервер IIS — это реализация внутрипроцессного сервера для IIS, в которой запрос преобразовывается из собственной формы в управляемую.

После того как HTTP-сервер IIS обработает запрос:

1. Запрос отправляется в конвейер ПО промежуточного слоя ASP.NET Core.
2. Конвейер ПО промежуточного слоя обрабатывает запрос и передает его в качестве экземпляра HttpContext в логику приложения.
3. Ответ приложения передается обратно в службы IIS через HTTP-сервер IIS.
4. IIS отправляет ответ клиенту, который инициировал запрос.

Внутрипроцессное размещение подходит для существующих приложений. В веб-шаблонах ASP.NET Core используется модель внутрипроцессного размещения.

CreateDefaultBuilder добавляет экземпляр IServer. При этом вызывается метод UseIIS для загрузки CoreCLR и размещения приложения внутри рабочего процесса IIS (w3wp.exe или iisexpress.exe). Тесты производительности демонстрируют, что размещение приложения внутри процесса .NET Core обеспечивает значительно более высокую пропускную способность по сравнению с размещением приложения вне процесса и направлению запросов через прокси-сервер к Kestrel.

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

Модель размещения вне процесса

Так как приложения ASP.NET Core выполняются в процессе, отделенном от рабочего процесса IIS, модуль ASP.NET Core обрабатывает управление процессами. Модуль запускает процесс для приложения ASP.NET Core при поступлении первого запроса и перезапускает приложение при сбое или завершении работы. Это, по сути, совпадает с поведением приложений, выполняемых внутрипроцессно и управляемых службой активации процессов Windows (WAS).

На следующей схеме показана связь между IIS, модулем ASP.NET Core и приложением, размещенным вне процесса.

1. Запросы поступают из Интернета в драйвер HTTP.sys в режиме ядра.
2. Драйвер направляет запросы к службам IIS на настроенный порт веб-сайта. Обычно это порт 80 (HTTP) или порт 443 (HTTPS).
3. Модуль пересылает запросы к Kestrel на случайный порт для приложения. В качестве случайного порта не могут использоваться порты 80 и 443.

Модуль ASP.NET Core задает порт с помощью переменной среды при запуске. Расширение UseIISIntegration настраивает сервер для прослушивания http://localhost:{PORT}. Выполняются дополнительные проверки, и запросы не из модуля отклоняются. Модуль не поддерживает переадресацию по HTTPS. Запросы переадресовываются по протоколу HTTP, даже если были получены IIS по протоколу HTTPS.

Когда Kestrel получает запрос от модуля, запрос перенаправляется в конвейер ПО промежуточного слоя ASP.NET Core. Конвейер ПО промежуточного слоя обрабатывает запрос и передает его в качестве экземпляра HttpContext в логику приложения. ПО промежуточного слоя, добавленное с использованием интеграции IIS, обновляет схему, удаленный IP-адрес и базовый путь с учетом перенаправления запроса к Kestrel. Ответ приложения передается обратно в службу IIS, которая пересылает его HTTP-клиенту, инициировавшему запрос.

Инструкции по настройке модуля ASP.NET Core см. в статье Модуль ASP.NET Core (ANCM) для IIS.

Дополнительные сведения о размещении см. в разделе Размещение в ASP.NET Core.

Конфигурация приложений

Включение компонентов IISIntegration

При создании узла в CreateHostBuilder (Program.cs) вызов для CreateDefaultBuilder включения интеграции IIS:

public static IHostBuilder CreateHostBuilder(string[] args) =>
    Host.CreateDefaultBuilder(args)
        ...

Дополнительные сведения о CreateDefaultBuilder см. в статье Универсальный узел .NET в ASP.NET Core.

Параметры служб IIS

Модель внутрипроцессного размещения

Чтобы настроить параметры сервера IIS, включите конфигурацию служб для IISServerOptions в ConfigureServices. В следующем примере показано, как отключить AutomaticAuthentication:

services.Configure<IISServerOptions>(options => 
{
    options.AutomaticAuthentication = false;
});

Вариант	По умолчанию.	Параметр
AutomaticAuthentication	true	Если значение — true, сервер IIS задает свойство HttpContext.User, использующее проверку подлинности Windows. Если falseсервер предоставляет identity HttpContext.User запросы только для и реагирует на проблемы, когда явно запрашивается сервером AuthenticationScheme. Для работы AutomaticAuthentication необходимо включить в службах IIS проверку подлинности Windows. Дополнительные сведения: Проверка подлинности Windows.
AuthenticationDisplayName	null	Задает отображаемое имя для пользователей на страницах входа.
AllowSynchronousIO	false	Разрешены ли синхронные операции ввода-вывода для HttpContext.Request и HttpContext.Response.
MaxRequestBodySize	30000000	Возвращает или задает максимальный размер текста запроса для HttpRequest. Обратите внимание, что сами службы IIS ограничены параметром maxAllowedContentLength, который обрабатывается перед тем, как MaxRequestBodySize задается в IISServerOptions. Изменение MaxRequestBodySize не влияет на maxAllowedContentLength. Чтобы увеличить maxAllowedContentLength, добавьте запись в web.config заданное maxAllowedContentLength значение более высокого значения. Дополнительные сведения см. в разделе Конфигурация.

Модель размещения вне процесса

Чтобы настроить параметры IIS, включите конфигурацию служб для IISOptions в ConfigureServices. В следующем примере приложению запрещается заполнение HttpContext.Connection.ClientCertificate:

services.Configure<IISOptions>(options => 
{
    options.ForwardClientCertificate = false;
});

Вариант	По умолчанию.	Параметр
AutomaticAuthentication	true	Если значение — true, ПО промежуточного слоя для интеграции IIS задает свойство HttpContext.User, которое прошло проверку подлинности Windows. Если falseпо промежуточному слоям предоставляется identity только возможность HttpContext.User и реагирование на проблемы при явном запросе AuthenticationScheme. Для работы AutomaticAuthentication необходимо включить в службах IIS проверку подлинности Windows. Дополнительные сведения см. в статье о проверке подлинности Windows.
AuthenticationDisplayName	null	Задает отображаемое имя для пользователей на страницах входа.
ForwardClientCertificate	true	Если значение — true и если присутствует заголовок запроса MS-ASPNETCORE-CLIENTCERT, происходит заполнение HttpContext.Connection.ClientCertificate.

Сценарии использования прокси-сервера и подсистемы балансировки нагрузки

ПО промежуточного слоя для интеграции IIS и модуль ASP.NET Core настроены для пересылки:

• схемы (HTTP/HTTPS);
• удаленного IP-адреса, на котором возник запрос.

ПО промежуточного слоя для интеграции IIS настраивает ПО промежуточного слоя переадресации заголовков.

Для приложений, размещенных за дополнительными прокси-серверами и подсистемами балансировки нагрузки, может потребоваться дополнительная настройка. Дополнительные сведения см. в разделе Настройка ASP.NET Core для работы с прокси-серверами и подсистемами балансировки нагрузки.

Файл web.config

В файле web.config содержится конфигурация модуля ASP.NET Core. Создание, преобразование и публикация web.config файла обрабатывается целевым объектом MSBuild (_TransformWebConfig) при публикации проекта. Этот целевой объект присутствует в целевых веб-пакетах SDK (Microsoft.NET.Sdk.Web). Пакет SDK задается в начале файла проекта:

<Project Sdk="Microsoft.NET.Sdk.Web">

Если в проекте нет файла web.config, он создается с правильными processPath и arguments для настройки модуля ASP.NET Core и переносится в опубликованные выходные данные.

web.config Если файл присутствует в проекте, файл преобразуется правильно и arguments настраивается processPath ASP.NET основной модуль и перемещается в опубликованные выходные данные. Преобразование не изменяет параметры конфигурации служб IIS, включенные в файл.

Файл web.config может предоставить дополнительные параметры конфигурации IIS, которые управляют активными модулями IIS. Сведения о модулях IIS, которые могут обрабатывать запросы к приложениям ASP.NET Core, см. в статье Модули IIS.

Чтобы веб-пакет SDK не преобразовывал файл web.config, используйте свойство <IsTransformWebConfigDisabled> в файле проекта:

<PropertyGroup>
  <IsTransformWebConfigDisabled>true</IsTransformWebConfigDisabled>
</PropertyGroup>

При отключении веб-пакета SDK от преобразования файла processPath необходимо arguments вручную задать разработчиком. Дополнительные сведения см. в разделе Модуль ASP.NET Core для IIS.

Расположение файла web.config

Для корректной настройки модуля ASP.NET Core необходимо наличие файла web.config в корневой папке содержимого развертываемого приложения (как правило, это основной путь приложения). Это расположение соответствует физическому пути веб-сайта, указанному в службах IIS. Файл web.config требуется в корне приложения, чтобы включить публикацию нескольких приложений с помощью веб-развертывания.

По физическому пути приложения находятся файлы с конфиденциальной информацией, например, {ASSEMBLY}.runtimeconfig.json, {ASSEMBLY}.xml (комментарии к XML-документации) и {ASSEMBLY}.deps.json, где заполнитель {ASSEMBLY} представляет собой имя сборки. web.config Когда файл присутствует и сайт запускается обычно, службы IIS не обслуживает эти конфиденциальные файлы, если они запрашиваются. web.config Если файл отсутствует, неправильно назван или не удается настроить сайт для нормального запуска, службы IIS могут предоставлять конфиденциальные файлы общедоступным образом.

Файл web.config должен постоянно присутствовать в развертывании, а также иметь правильное имя и возможность настроить сайт для нормального запуска. Никогда не удаляйте файл web.config из развертывания в рабочей среде.

Преобразование web.config

Если вам нужно преобразовать web.config при публикации, см. статью Преобразование web.config. Возможно, вам потребуется выполнить преобразование web.config при публикации, чтобы задать переменные среды на основе конфигурации, профиля или среды.

Конфигурация IIS

ОС Windows Server

Включите роль сервера Веб-сервер (IIS) и настройте службы роли.

1. В меню Управление запустите мастер Добавить роли и компоненты или в окне Диспетчер серверов щелкните соответствующую ссылку. На этапе Роли сервера установите флажок Веб-сервер (IIS).

   

2. После этапа выбора компонентов запускается этап выбора служб роли для веб-сервера (IIS). Выберите нужные службы роли IIS или оставьте службы по умолчанию.

   

   Проверка подлинности Windows (необязательный компонент)
   Чтобы включить проверку подлинности Windows, разверните такие узлы: Веб-сервер>Безопасность. Выберите компонент Проверка подлинности Windows. Дополнительные сведения см. в статьях Проверка подлинности Windows <windowsAuthentication> и Настройка проверки подлинности Windows.

   Протокол WebSocket (необязательный компонент)
   Протокол WebSocket поддерживается в ASP.NET Core начиная с версии 1.1. Чтобы включить протокол WebSocket, разверните такие узлы: Веб-сервер>Разработка приложений. Выберите компонент Протокол WebSocket. Дополнительные сведения см. в разделе Протокол WebSocket.

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

Операционные системы Windows для настольных компьютеров

Включите компоненты Консоль управления IIS и Службы Интернета.

1. Последовательно выберите Панель управления>Программы>Программы и компоненты>Включение или отключение компонентов Windows (в левой части экрана).

2. Разверните узел Службы IIS. Разверните узел Средства управления веб-сайтом.

3. Установите флажок Консоль управления IIS.

4. Установите флажок Службы Интернета.

5. В группе Службы Интернета оставьте компоненты по умолчанию или настройте компоненты IIS.

   Проверка подлинности Windows (необязательный компонент)
   Чтобы включить проверку подлинности Windows, разверните такие узлы: Службы Интернета>Безопасность. Выберите компонент Проверка подлинности Windows. Дополнительные сведения см. в статьях Аутентификация Windows<windowsAuthentication> и Настройка аутентификации Windows в приложении ASP.NET Core.

   Протокол WebSocket (необязательный компонент)
   Протокол WebSocket поддерживается в ASP.NET Core начиная с версии 1.1. Чтобы включить протокол WebSocket, разверните такие узлы: Службы Интернета>Компоненты разработки приложений. Выберите компонент Протокол WebSocket. Дополнительные сведения см. в разделе Протокол WebSocket.

6. Если во время установки IIS потребуется перезагрузка, перезагрузите систему.

Установка пакета размещения .NET Core

Установите пакет размещения .NET Core в размещающей системе. В составе пакета устанавливаются среда выполнения .NET Core, библиотека .NET Core и модуль ASP.NET Core. Модуль позволяет запускать приложения ASP.NET Core под управлением IIS.

Прямая загрузка (текущая версия)

Скачайте установщик по следующей ссылке:

Текущий установщик пакета размещения .NET Core (прямая загрузка)

Более ранние версии установщика

Получение более ранней версии установщика:

1. Перейдите на страницу загрузки .NET Core.
2. Выберите требуемую версию .NET Core.
3. В столбце Запуск приложений — среда выполнения найдите строку, содержащую нужную версию среды выполнения .NET Core.
4. Скачайте установщик по ссылке Hosting Bundle (Пакет размещения).

Установка пакета размещения .NET Core

1. Запустите установщик на сервере. При запуске установщика из командной оболочки администратора доступны следующие параметры:

   • OPT_NO_ANCM=1: пропустите установку модуля ASP.NET Core.
   • OPT_NO_RUNTIME=1: пропустить установку среды выполнения .NET Core. Используется, когда на сервере размещаются только автономные развертывания.
   • OPT_NO_SHAREDFX=1: пропустите установку ASP.NET Shared Framework (среда выполнения ASP.NET). Используется, когда на сервере размещаются только автономные развертывания.
   • OPT_NO_X86=1: пропустить установку сред выполнения x86. Этот параметр следует использовать, если вы наверняка не будете размещать 32-разрядные приложения. Если есть хоть малейшая возможность, что в будущем придется размещать и 32-разрядные, и 64-разрядные приложения, не указывайте этот параметр и установите обе среды выполнения.
   • OPT_NO_SHARED_CONFIG_CHECK=1: отключите проверку использования общей конфигурации IIS, если общая конфигурация (applicationHost.config) находится на том же компьютере, что и установка IIS. Доступен только для пакетных установщиков размещения ASP.NET Core 2.2 или более поздней версии. Дополнительные сведения см. в разделе Модуль ASP.NET Core для IIS.

2. Перезапуск служб IIS позволит обнаружить внесенные установщиком изменения в системном пути, который является переменной среды. Чтобы перезапустить веб-сервер, завершите работу службы активации Windows (WAS), а затем перезапустите службу веб-публикаций (W3SVC). Перезапустите систему или выполните в командной оболочке с повышенными привилегиями следующие команды:

   net stop was /y
   net start w3svc
   

ASP.NET Core не наследует поведение наката для выпусков исправлений пакетов общей платформы. После обновления общей платформы путем установки нового пакета размещения перезапустите систему или выполните в командной оболочке с повышенными привилегиями следующие команды:

net stop was /y
net start w3svc

Установка веб-развертывания при публикации с помощью Visual Studio

При развертывании приложений на серверах с помощью веб-развертывания установите на сервере последнюю версию веб-развертывания. Чтобы установить веб-развертывание, используйте установщик веб-платформы (WebPI) или просмотрите файлы загрузки IIS: веб-развертывание. Предпочтительный метод — использовать WebPI. WebPI обеспечивает автономную установку и настройку поставщиков размещения.

Создание сайта IIS

1. В размещающей системе создайте папку, в которой будут храниться файлы и папки опубликованного приложения. На следующем этапе путь к папке предоставляется IIS как физический путь к приложению. Дополнительные сведения о папке развертывания и структуре файлов приложения см. в статье Структура каталогов ASP.NET Core.

2. В окне диспетчера IIS на панели Подключения разверните узел сервера. Щелкните правой кнопкой мыши папку Сайты. В контекстном меню выберите пункт Добавить веб-сайт.

3. Укажите имя в поле Имя сайта и задайте значение в поле Физический путь для созданной папки развертывания приложения. Укажите конфигурацию привязки и нажмите кнопку ОК, чтобы создать веб-сайт.

   

   Предупреждение

   Не используйте привязки с подстановочными знаками (http://*:80/ и http://+:80) на верхнем уровне. Это может создать уязвимость и поставить ваше приложение под угрозу. Сюда относятся и строгие, и нестрогие подстановочные знаки. Вместо этого используйте имена узлов в явном виде. Привязки с подстановочными знаками на уровне дочерних доменов (например *.mysub.com) не создают таких угроз безопасности, если вы полностью контролируете родительский домен (в отличие от варианта *.com, создающего уязвимость). Дополнительные сведения см. в разделе RFC 9110: семантика HTTP (раздел 7.2: host и :authority).

4. Разверните узел сервера и выберите Пулы приложений.

5. Щелкните правой кнопкой мыши пул приложений сайта и в контекстном меню выберите пункт Основные параметры.

6. В окне Изменение пула приложений задайте для параметра Версия среды CLR .NET значение Без управляемого кода.

   

   ASP.NET Core выполняется в отдельном процессе и управляет средой выполнения. Для ASP.NET Core не требуется загрузка классической среды CLR (.NET CLR). Для размещения приложения в рабочем процессе запускается CoreCLR для .NET Core. Задавать для параметра Версия среды CLR .NET значение Без управляемого кода необязательно, но рекомендуется.

7. ASP.NET Core 2.2 или более поздней версии:

   • Для 32-разрядного (x86) автономного развертывания, опубликованного с помощью 32-разрядного пакета SDK, в котором используется модель размещения в процессе, включите пул приложений для 32-разрядной архитектуры. В диспетчере IIS перейдите в раздел Пулы приложений на боковой панели Подключения. Выберите пул приложений приложения. На боковой панели Действия выберите Дополнительные параметры. Установите для параметра Включить 32-разрядные приложения значение True.

   • для 64-разрядного (x64) автономного развертывания, в котором используется модель размещения в процессе, отключите пул приложений для 32-разрядных (x86) процессов. В диспетчере IIS перейдите в раздел Пулы приложений на боковой панели Подключения. Выберите пул приложений приложения. На боковой панели Действия выберите Дополнительные параметры. Установите для параметра Включить 32-разрядные приложения значение False.

8. Убедитесь, что модель identity процесса имеет соответствующие разрешения.

   Если по умолчанию identity пул приложений (модельIdentity> обработки) изменяется с ApplicationPoolIdentity на другойidentity, убедитесь, что у нового identity есть необходимые разрешения для доступа к папке приложения, базе данных и другим необходимым ресурсам. Например, пулу приложений требуются права на чтение и запись в папках, в которых приложение считывает и записывает файлы.

Настройка проверки подлинности Windows (необязательный этап)
См. статью Configure Windows authentication in an ASP.NET Core app (Настройка проверки подлинности Windows в приложении ASP.NET Core).

Развертывание приложения

Разверните приложение в папке IIS, физический путь к которой вы указали в рамках раздела Создание сайта IIS. Рекомендуется выполнять веб-развертывание, но есть несколько других способов переместить приложение из папки publish проекта в папку развертывания размещающей системы.

Веб-развертывание с помощью Visual Studio

Сведения о создании профиля публикации для веб-развертывания см. в статье Профили публикации Visual Studio для развертывания приложений ASP.NET Core. Если поставщик услуг размещения предоставляет профиль публикации или позволяет его создать, скачайте этот профиль и импортируйте его с помощью диалогового окна Публикация в Visual Studio:

Веб-развертывание вне Visual Studio

Веб-развертывание можно также использовать вне Visual Studio с помощью командной строки. Дополнительные сведения см. в статье Средство веб-развертывания.

Альтернативы веб-развертыванию

Переместить приложение в размещающую систему можно несколькими способами: с помощью копирования вручную, Xcopy, Robocopy или PowerShell.

Дополнительные сведения о развертывании ASP.NET Core в службах IIS см. в разделе Ресурсы развертывания для администраторов IIS.

Открытие веб-сайта в браузере

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

В приведенном ниже примере сайт привязан к имени узла IIS www.mysite.com в порте 80. Запрос отправляется по адресу http://www.mysite.com:

Заблокированные файлы развертывания

Во время выполнения приложения файлы в папке развертывания блокируются. Заблокированные файлы невозможно перезаписать во время развертывания. Чтобы снять блокировку с файлов в развертывании, остановите пул приложений с помощью одного из следующих методов:

• Запустите веб-развертывание и добавьте ссылку на Microsoft.NET.Sdk.Web в файл проекта. Файл app_offline.htm помещается в корневой каталог веб-приложения. Когда файл присутствует, модуль ядра ASP.NET корректно завершает работу приложения и обслуживает app_offline.htm файл во время развертывания. Дополнительные сведения см. в разделе Справочник по конфигурации модуля ASP.NET Core.

• Вручную остановите пул приложений в диспетчере служб IIS на сервере.

• Используйте PowerShell для удаления app_offline.htm (требуется PowerShell 5 или более поздней версии):

  $pathToApp = 'PATH_TO_APP'
  
  # Stop the AppPool
  New-Item -Path $pathToApp app_offline.htm
  
  # Provide script commands here to deploy the app
  
  # Restart the AppPool
  Remove-Item -Path $pathToApp app_offline.htm
  

Защита данных

Стек защиты данных ASP.NET Core используют несколько ПО промежуточного слоя ASP.NET Core, включая ПО, которое применяется для аутентификации. Даже если API-интерфейсы защиты данных не вызываются из пользовательского кода, защиту данных следует настроить для создания постоянного хранилища криптографических ключей. Это можно сделать с помощью скрипта развертывания или в пользовательском коде. Если защита данных не настроена, ключи хранятся в памяти и удаляются при перезапуске приложения.

Если набор ключей хранится в памяти, при перезапуске приложения происходит следующее:

• Все токены аутентификации, использующие файлы cookie, становятся недействительными.
• При выполнении следующего запроса пользователю требуется выполнить вход снова.
• Все данные, защищенные с помощью набора ключей, больше не могут быть расшифрованы. Это могут быть токены CSRF и файлы cookie временных данных ASP.NET Core MVC.

Чтобы настроить защиту данных в службах IIS для хранения набора ключей, воспользуйтесь одним из следующих методов:

• Создание раздела реестра для защиты данных.

  Ключи защиты данных, используемые приложениями ASP.NET Core, хранятся во внешнем для приложений реестре. Чтобы хранить эти ключи для определенного приложения, нужно создать разделы реестра для пула приложений.

  При автономной установке служб IIS, не поддерживающей веб-ферму, можно выполнить скрипт PowerShell Provision-AutoGenKeys.ps1 для защиты данных применительно к каждому пулу приложений, в который входит приложение ASP.NET Core. Этот скрипт создает раздел в реестре HKLM, который будет доступен только для учетной записи рабочего процесса пула приложений, к которому относится соответствующее приложение. Ключи шифруются rest с помощью DPAPI с ключом на уровне компьютера.

  В случаях, когда используется веб-ферма, в приложении можно настроить UNC-путь, по которому это приложение будет хранить набор ключей для защиты данных. По умолчанию ключи защиты данных не шифруются. Разрешения на доступ к файлам в сетевой папке должны быть предоставлены только учетной записи Windows, с помощью которой выполняется приложение. Сертификат X509 можно использовать для защиты ключей.rest Рассмотрите возможность реализации механизма, позволяющего пользователям отправлять сертификаты: поместить сертификаты в хранилище доверенных сертификатов пользователя и обеспечивать их доступность на всех компьютерах, где выполняется приложение. Дополнительные сведения см. в разделе Настройка защиты данных в ASP.NET Core.

• Настройка пула приложений IIS для загрузки профиля пользователя.

  Этот параметр находится на странице Дополнительные параметры пула приложений в разделе Модель процесса. Задайте для параметра Загрузить профиль пользователя значение True. Если задать значение True, ключи будут храниться в каталоге профиля пользователя и защищаться с помощью API защиты данных и ключа на уровне учетной записи пользователя. Ключи хранятся в папке %LOCALAPPDATA%/ASP.NET/DataProtection-Keys.

  Также необходимо включить атрибут setProfileEnvironment пула приложений. Значение setProfileEnvironment по умолчанию — true. В некоторых сценариях (например, в ОС Windows) для параметра setProfileEnvironment установлено значение false. Если ключи не хранятся в каталоге профиля пользователя:

  1. Перейдите к папке %windir%/system32/inetsrv/config.
  2. Откройте файл applicationHost.config.
  3. Найдите элемент <system.applicationHost><applicationPools><applicationPoolDefaults><processModel>.
  4. Убедитесь, что атрибут setProfileEnvironment отсутствует и установлено значение по умолчанию true, или же явно задайте для атрибута значение true.

• Использование файловой системы в качестве хранилища набора ключей.

  Измените код приложения так, чтобы в качестве хранилища набора ключей использовалась файловая система. Для защиты набора ключей используйте доверенный сертификат X509. Если сертификат — самозаверяющий, поместите его в доверенное корневое хранилище.

  При использовании служб IIS в веб-ферме:

  • используйте общую папку, которая доступна всем компьютерам;
  • разверните сертификат X509 на каждом компьютере; настройте защиту данных в коде.

• Настройка политики защиты данных на уровне компьютера.

  Система защиты данных обеспечивает ограниченную поддержку задания политики по умолчанию на уровне компьютера для всех приложений, использующих интерфейсы API защиты данных. Дополнительные сведения см. в статье Защита данных в ASP.NET Core.

Виртуальные каталоги

Виртуальные каталоги IIS не поддерживаются в приложениях ASP.NET Core. Приложение может размещаться как вложенное.

Вложенные приложения

Приложение ASP.NET Core можно разместить как вложенное приложение IIS. Путь к вложенному приложению становится частью URL-адреса главного приложения.

В ссылках на статический ресурс во вложенном приложении следует использовать нотацию ~/. Такая нотация активирует вспомогательную функцию тега для добавления свойства pathbase вложенного приложения в начало отображаемой относительной ссылки. Для вложенного приложения с путем /subapp_path ссылка на изображение src="~/image.png" отображается как src="/subapp_path/image.png". ПО промежуточного слоя для обработки статических файлов в главном приложении не обрабатывает такой запрос статического файла. Запрос обрабатывается соответствующим ПО вложенного приложения.

Если атрибуту src статического ресурса присваивается абсолютный путь (например, src="/image.png"), ссылка отображается без свойства pathbase вложенного приложения. ПО промежуточного слоя для обработки статических файлов в главном приложении пытается найти ресурс в корневом веб-каталоге главного приложения, что приводит к ошибке 404 — Not Found (не найдено), кроме случаев, когда статический ресурс доступен из главного приложения.

Для размещения приложения ASP.NET Core в качестве приложения, вложенного в другое приложение ASP.NET Core, сделайте следующее:

1. Создайте пул приложений для вложенного приложения. Установите для параметра Версия среды CLR .NET значение Без управляемого кода, так как для размещения приложения в рабочем процессе запускается CoreCLR для .NET Core, а не среда CRL для настольных ПК (.NET CLR).

2. Добавьте корневой веб-сайт в диспетчере служб IIS с вложенным приложением в папке внутри корневого веб-сайта.

3. Щелкните правой кнопкой мыши папку вложенного приложения в диспетчере служб IIS и выберите Преобразовать в приложение.

4. В диалоговом окне Добавление приложения нажмите кнопку Выбрать, чтобы назначить созданный пул приложений вложенному приложению. Нажмите ОК.

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

Дополнительные сведения о внутрипроцессной модели размещения и настройке модуля ASP.NET Core см. в статье Модуль ASP.NET Core (ANCM) для IIS.

Настройка служб IIS с помощью файла web.config

Конфигурация IIS зависит от <system.webServer> раздела web.config для сценариев IIS, предназначенных для работы приложений ASP.NET Core с помощью модуля ASP.NET Core. Например, конфигурация IIS работает для динамического сжатия. Если в службах IIS на уровне сервера настроено динамическое сжатие, элемент <urlCompression> в файле web.config приложения может отключить это сжатие для приложения ASP.NET Core.

Дополнительные сведения см. в следующих разделах:

• Справочник по настройке для <system.webServer>
• модуль ASP.NET Core (ANCM) для IIS
• Модули IIS с ASP.NET Core

Сведения о настройке переменных среды для отдельных приложений, выполняющихся в изолированных пулах приложений (такая возможность поддерживается в службах IIS начиная с версии 10.0), см. в справочной документации по службам IIS, в частности в разделе AppCmd.exe статьи Environment Variables <environmentVariables> (Переменные среды ).

Разделы, которые не используются ASP.NET Core

Разделы конфигурации приложений ASP.NET в файле web.config не используются для настройки приложений ASP.NET Core:

• <system.web>
• <appSettings>
• <connectionStrings>
• <location>

Для настройки приложений ASP.NET Core используются другие поставщики конфигураций. Дополнительные сведения см. в разделах Конфигурация и Параметры среды выполнения .NET Core.

Пулы приложений

Модель размещения определяет изоляцию пула приложений:

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

В диалоговом окне Добавление веб-сайта IIS на каждое приложение по умолчанию задан один пул приложений. Если указано Имя сайта, оно автоматически переносится в текстовое поле Пул приложений. При добавлении веб-сайта создается пул приложений с именем сайта.

Identity пула приложений

Учетная запись пула identity приложений позволяет приложению работать под уникальной учетной записью, не создавая домены или локальные учетные записи и управляя ими. В службах IIS начиная с версии 8.0 рабочий процесс администратора IIS (WAS) создает виртуальную учетную запись с именем нового пула приложений и по умолчанию выполняет рабочие процессы пула приложений с помощью этой учетной записи. В консоли управления IIS в окне Дополнительные параметры пула приложений для Identity необходимо выбрать ApplicationPoolIdentity.

Процесс управления IIS создает в системе безопасности Windows безопасный идентификатор с именем пула приложений. С помощью этого identityсредства можно защитить ресурсы. Однако это identity не реальная учетная запись пользователя и не отображается в консоли управления пользователями Windows.

Если рабочему процессу IIS требуется предоставить доступ к приложению с повышенными правами, измените список управления доступом (ACL) для каталога, содержащего приложение.

1. Откройте проводник и перейдите к каталогу.

2. Щелкните каталог правой кнопкой мыши и выберите пункт Свойства.

3. На вкладке Безопасность нажмите кнопку Изменить, а затем — кнопку Добавить.

4. Нажмите кнопку Размещение и выберите систему.

5. Введите IIS AppPool\{APP POOL NAME}, где заполнитель {APP POOL NAME} представляет собой имя пула приложения, в области Введите имена объектов для выбора. Нажмите кнопку Проверить имена. В случае с DefaultAppPool проверьте имена с помощью IIS AppPool\DefaultAppPool. После нажатия кнопки Проверить имена в области имен объектов отобразится значение DefaultAppPool. Вручную ввести имя пула приложений в области имен объектов нельзя. При проверке имени объекта используйте формат IIS AppPool\{APP POOL NAME}, где заполнитель {APP POOL NAME} представляет собой имя пула приложения.

   

6. Нажмите ОК.

   

7. Разрешения на чтение и выполнение должны быть предоставлены по умолчанию. При необходимости предоставьте дополнительные разрешения.

Кроме того, доступ можно предоставить через командную строку, используя средство ICACLS. DefaultAppPool В качестве примера используется следующая команда:

ICACLS C:\sites\MyWebApp /grant "IIS AppPool\DefaultAppPool":F

Дополнительные сведения об ICACLS см. здесь.

Поддержка HTTP/2

HTTP/2 поддерживается в ASP.NET Core для следующих сценариев развертывания IIS:

• Внутрипроцессный процесс
  • Windows Server 2016 / Windows 10 или более поздних версий; IIS 10 или более поздней версии
  • Подключение TLS 1.2 или более поздней версии
• Внепроцессный процесс
  • Windows Server 2016 / Windows 10 или более поздних версий; IIS 10 или более поздней версии
  • Общедоступные подключения пограничного сервера используют HTTP/2, однако обратное прокси-соединение с Kestrel сервером использует HTTP / 1.1.
  • Подключение TLS 1.2 или более поздней версии

При внутрипроцессном развертывании и установленном подключении HTTP/2 HttpRequest.Protocol возвращает HTTP/2. При внепроцессном развертывании и установленном подключении HTTP/2 HttpRequest.Protocol возвращает HTTP/1.1.

Дополнительные сведения о внутри- и внепроцессных моделях размещения см. в статье Модуль ASP.NET Core (ANCM) для IIS.

Протокол HTTP/2 по умолчанию включен. Если не удается установить подключение HTTP/2, применяется резервный вариант HTTP/1.1. Дополнительные сведения о настройке HTTP/2 для развертываний IIS см. в статье об HTTP/2 в IIS.

Предварительные запросы CORS

Этот раздел относится только к приложениям ASP.NET Core, предназначенным для .NET Framework.

Для приложения ASP.NET Core, предназначенного для .NET Framework, параметры OPTIONS не передаются в приложение по умолчанию в службах IIS. Чтобы узнать, как настроить обработчики приложения IIS в файле web.config для передачи запросов OPTIONS, см. статью Включение запросов о происхождении (CORS) в веб-API 2 ASP.NET.

Модуль инициализации приложений и время ожидания в режиме простоя

Размещение в IIS с помощью модуля ASP.NET Core версии 2:

• Модуль инициализации приложений: размещенный внутри процесса или внепроцессный модуль приложения можно настроить для автоматического запуска рабочего процесса перезапуска или перезапуска сервера.
• Время ожидания простоя: размещенные в процессе приложения можно настроить не время ожидания в периоды бездействия.

Модуль инициализации приложений

Применяется к приложениям, размещенным в процессе и вне процесса.

Функция инициализации приложений в IIS отправляет в приложение HTTP-запрос при запуске или перезапуске пула приложений. Этот запрос инициирует запуск приложения. По умолчанию IIS отправляет запрос к корневому URL-адресу приложения (/) для его инициализации (подробные сведения о конфигурации см. в дополнительных ресурсах).

Убедитесь, что включена роль инициализации приложения IIS.

На настольных компьютерах с Windows 7 или более поздней версии при локальном использовании IIS:

1. Последовательно выберите Панель управления>Программы>Программы и компоненты>Включение или отключение компонентов Windows (в левой части экрана).
2. Откройте Службы IIS>Службы Интернета>Компоненты разработки приложений.
3. Установите флажок Инициализация приложений.

В Windows Server 2008 R2 и более поздней версии:

1. Откройте Мастер добавления ролей и компонентов.
2. На панели Выбор служб ролей разверните узел Разработка приложений.
3. Установите флажок Инициализация приложений.

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

• При использовании диспетчера IIS:

  1. Выберите Пулы приложений на панели Подключения.
  2. Щелкните пул приложений в списке правой кнопкой мыши и выберите Дополнительные параметры.
  3. Для режима запуска по умолчанию задано значение OnDemand. Выберите для параметра Режим запуска значение AlwaysRunning. Нажмите ОК.
  4. Откройте узел Сайты на панели Подключения.
  5. Щелкните приложение правой кнопкой мыши и выберите Управление веб-сайтом>Дополнительные параметры.
  6. По умолчанию для параметра Предварительная загрузка включена установлено значение False. Для параметра Предварительная загрузка включена выберите значение True. Нажмите ОК.

• Откройте web.config и добавьте элемент <applicationInitialization> с параметром doAppInitAfterRestart, для которого установлено значение true, к элементам <system.webServer> в файле web.config приложения:

  <?xml version="1.0" encoding="utf-8"?>
  <configuration>
    <location path="." inheritInChildApplications="false">
      <system.webServer>
        <applicationInitialization doAppInitAfterRestart="true" />
      </system.webServer>
    </location>
  </configuration>
  

Время ожидания перед переходом в режим простоя

Применяется только к приложениям, размещенным в процессе.

Чтобы предотвратить переход приложения из состояния простоя, задайте для пула приложений время ожидания в режиме простоя с помощью диспетчера IIS:

1. Выберите Пулы приложений на панели Подключения.
2. Щелкните пул приложений в списке правой кнопкой мыши и выберите Дополнительные параметры.
3. По умолчанию для параметра Тайм-аут простоя (в минутах) установлено значение 20 минут. Задайте для параметра Тайм-аут простоя (в минутах) значение 0. Нажмите ОК.
4. Перезапустите рабочий процесс.

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

• Проверьте связь с приложением из внешней службы, чтобы оно продолжило работу.
• Если приложение размещает только фоновые службы, избегайте размещения в службах IIS и воспользуйтесь службой Windows для размещения приложения ASP.NET Core.

Дополнительные ресурсы по модулю инициализации приложений и времени ожидания в режиме простоя

• Инициализация приложений в IIS 8.0
• Инициализация приложений: элемент <applicationInitialization>.
• Параметры модели процессов для пула приложений: элемент <processModel>.

Ресурсы развертывания для администраторов IIS

• Документация по службам IIS
• Начало работы с диспетчером IIS в IIS
• Развертывание приложений .NET Core
• модуль ASP.NET Core (ANCM) для IIS
• структура каталогов ASP.NET Core
• Модули IIS с ASP.NET Core
• Устранение неполадок ASP.NET Core в службе приложение Azure и IIS
• Устранение распространенных неполадок в Службе приложений Azure и службах IIS с помощью ASP.NET Core

Дополнительные ресурсы

• Устранение неполадок и отладка проектов ASP.NET Core
• Общие сведения об ASP.NET Core
• Официальный веб-сайт Microsoft IIS
• Библиотека технического содержимого по Windows Server
• HTTP/2 on IIS (HTTP/2 в IIS)
• Преобразование web.config

Руководство по публикации приложения ASP.NET Core на сервере IIS см. здесь: Публикация приложения ASP.NET Core в службах IIS.

Установка пакета размещения .NET Core

Поддерживаемые операционные системы

Поддерживаются следующие операционные системы:

• Windows 7 или более поздней версии.
• Windows Server 2008 R2 или более поздней версии

Сервер HTTP.sys (ранее назывался WebListener) не работает в конфигурации обратного прокси-сервера со службами IIS. Используйте Kestrelсервер.

Дополнительные сведения о размещении в Azure см. в статье Развертывание приложений ASP.NET Core в Службе приложений Azure.

Рекомендации по устранению неполадок см. в статье Устранение неполадок и отладка проектов ASP.NET Core.

Поддерживаемые платформы

Поддерживаются приложения, опубликованные для развертывания в 32-разрядных (x86) или 64-разрядных (x64) системах. Развертывайте 32-разрядную версию (x86) приложения с использованием 32-разрядного пакета SDK для .NET Core, кроме следующих случаев:

• Приложению требуется более широкое адресное пространство виртуальной памяти, доступное в 64-разрядной версии приложения.
• Приложению требуется стек IIS большего размера.
• В коде присутствуют зависимости 64-разрядной версии.

Используйте 64-разрядный (x64) пакет SDK для .NET Core для публикации 64-разрядной версии приложения. Для этого в системе узла должна присутствовать 64-разрядная версия среды выполнения.

ASP.NET Core поставляется с Kestrel сервером, межплатформенным HTTP-сервером по умолчанию.

При использовании IIS или IIS Express приложение запускается в процессе, отдельном от рабочего процесса IIS (внепроцессный) с Kestrel сервер .

Так как приложения ASP.NET Core выполняются в процессе, отделенном от рабочего процесса IIS, этот модуль обрабатывает управление процессами. Модуль запускает процесс для приложения ASP.NET Core при поступлении первого запроса и перезапускает приложение при сбое или завершении работы. Это, по сути, совпадает с поведением приложений, выполняемых внутрипроцессно и управляемых службой активации процессов Windows (WAS).

На следующей схеме показана связь между IIS, модулем ASP.NET Core и приложением, размещенным вне процесса.

Запросы поступают из Интернета в драйвер HTTP.sys в режиме ядра. Драйвер направляет запросы к службам IIS на настроенный порт веб-сайта — обычно 80 (HTTP) или 443 (HTTPS). Модуль перенаправляет запросы к Kestrel на случайный порт для приложения, который не является портом 80 или 443.

Модуль задает порт с помощью переменной среды во время запуска, а ПО промежуточного слоя для интеграции IIS настраивает сервер для прослушивания http://localhost:{port}. Выполняются дополнительные проверки, и запросы не из модуля отклоняются. Модуль не поддерживает переадресацию по HTTPS, поэтому запросы переадресовываются по протоколу HTTP, даже если были получены IIS по протоколу HTTPS.

После того, как Kestrel получает запрос от модуля, запрос передается в конвейер ПО промежуточного слоя ASP.NET Core. Конвейер ПО промежуточного слоя обрабатывает запрос и передает его в качестве экземпляра HttpContext в логику приложения. ПО промежуточного слоя, добавленное с использованием интеграции IIS, обновляет схему, удаленный IP-адрес и базовый путь с учетом перенаправления запроса к Kestrel. Отклик приложения передается обратно в службу IIS, которая отправляет его обратно в HTTP-клиент, инициировавший запрос.

CreateDefaultBuilder настраивает сервер Kestrel как веб-сервер и включает интеграцию IIS, настраивая базовый путь и порт для Модуля ASP.NET Core.

Модуль ASP.NET Core создает динамический порт для назначения серверному процессу. CreateDefaultBuilder вызывает метод UseIISIntegration. UseIISIntegration настраивает Kestrel для прослушивания динамического порта на IP-адресе локального хоста (127.0.0.1). Если динамический порт - 1234, Kestrel прослушивает 127.0.0.1:1234. Эта конфигурация заменяет другие конфигурации URL-адресов, предоставляемые:

• UseUrls
• KestrelAPI прослушивания
• Конфигурацией (или параметром командной строки--urls).

При использовании модуля вызовы API UseUrls или Kestrel Listen не требуются. При вызове UseUrls или Listen, Kestrel прослушивает указанный порт только при запуске приложения без IIS.

Инструкции по настройке модуля ASP.NET Core см. в статье Модуль ASP.NET Core (ANCM) для IIS.

Дополнительные сведения о размещении см. в разделе Размещение в ASP.NET Core.

Конфигурация приложений

Включение компонентов IISIntegration

При создании узла в CreateWebHostBuilder (Program.cs) вызов для CreateDefaultBuilder включения интеграции IIS:

public static IWebHostBuilder CreateWebHostBuilder(string[] args) =>
    WebHost.CreateDefaultBuilder(args)
        ...

Дополнительные сведения о CreateDefaultBuilder см. в статье Веб-узел ASP.NET Core.

Параметры служб IIS

Вариант	По умолчанию.	Параметр
AutomaticAuthentication	true	Если значение — true, сервер IIS задает свойство HttpContext.User, использующее проверку подлинности Windows. Если falseсервер предоставляет identity HttpContext.User запросы только для и реагирует на проблемы, когда явно запрашивается сервером AuthenticationScheme. Для работы AutomaticAuthentication необходимо включить в службах IIS проверку подлинности Windows. Дополнительные сведения: Проверка подлинности Windows.
AuthenticationDisplayName	null	Задает отображаемое имя для пользователей на страницах входа.

Чтобы настроить параметры IIS, включите конфигурацию служб для IISOptions в ConfigureServices. В следующем примере приложению запрещается заполнение HttpContext.Connection.ClientCertificate:

services.Configure<IISOptions>(options => 
{
    options.ForwardClientCertificate = false;
});

Вариант	По умолчанию.	Параметр
AutomaticAuthentication	true	Если значение — true, ПО промежуточного слоя для интеграции IIS задает свойство HttpContext.User, которое прошло проверку подлинности Windows. Если falseпо промежуточному слоям предоставляется identity только возможность HttpContext.User и реагирование на проблемы при явном запросе AuthenticationScheme. Для работы AutomaticAuthentication необходимо включить в службах IIS проверку подлинности Windows. Дополнительные сведения см. в статье о проверке подлинности Windows.
AuthenticationDisplayName	null	Задает отображаемое имя для пользователей на страницах входа.
ForwardClientCertificate	true	Если значение — true и если присутствует заголовок запроса MS-ASPNETCORE-CLIENTCERT, происходит заполнение HttpContext.Connection.ClientCertificate.

Сценарии использования прокси-сервера и подсистемы балансировки нагрузки

ПО промежуточного слоя для интеграции IIS, которое настраивает ПО промежуточного слоя переадресации заголовков, и модуль ASP.NET Core настраиваются на пересылку схемы (HTTP/HTTPS) и удаленного IP-адреса расположения, где был сформирован запрос. Для приложений, размещенных за дополнительными прокси-серверами и подсистемами балансировки нагрузки, может потребоваться дополнительная настройка. Дополнительные сведения см. в разделе Настройка ASP.NET Core для работы с прокси-серверами и подсистемами балансировки нагрузки.

файл web.config

В файле web.config содержится конфигурация модуля ASP.NET Core. Создание, преобразование и публикация файла web.config обрабатываются целевым объектом MSBuild (_TransformWebConfig) при публикации проекта. Этот целевой объект присутствует в целевых веб-пакетах SDK (Microsoft.NET.Sdk.Web). Пакет SDK задается в начале файла проекта:

<Project Sdk="Microsoft.NET.Sdk.Web">

Если в проекте нет файла web.config, он создается с соответствующими аргументами processPath и arguments для настройки модуля ASP.NET Core и переносится в опубликованные выходные данные.

Если в проекте есть файл web.config, он преобразуется с соответствующими аргументами processPath и arguments для настройки модуля ASP.NET Core и переносится в опубликованные выходные данные. Преобразование не изменяет параметры конфигурации служб IIS, включенные в файл.

Файл web.config может содержать дополнительные параметры конфигурации IIS, управляющие активными модулями IIS. Сведения о модулях IIS, которые могут обрабатывать запросы к приложениям ASP.NET Core, см. в статье Модули IIS.

Чтобы пакет SDK не преобразовывал файл web.config, добавьте в файл проекта свойство <IsTransformWebConfigDisabled>:

<PropertyGroup>
  <IsTransformWebConfigDisabled>true</IsTransformWebConfigDisabled>
</PropertyGroup>

Если пакет SDK не преобразует файл, аргументы processPath и arguments нужно задать вручную. Дополнительные сведения см. в разделе Модуль ASP.NET Core для IIS.

Расположение файла web.config

Для корректной настройки модуля ASP.NET Core необходимо наличие файла web.config в корневой папке содержимого развертываемого приложения (как правило, это основной путь приложения). Это расположение соответствует физическому пути веб-сайта, указанному в службах IIS. Файл web.config требуется в корне приложения, чтобы разрешить публикацию нескольких приложений с помощью веб-развертывания.

По физическому пути приложения находятся файлы с конфиденциальной информацией: <имя_сборки>.runtimeconfig.json, <имя_сборки>.xml (комментарии к XML-документации) и <имя_сборки>.deps.json. Когда файл web.config присутствует и сайт запускается нормально, службы IIS не обрабатывают запросы к этим файлам. Если файл web.config отсутствует, неправильно именован или не может настроить нормальный запуск сайта, службы IIS могут свободно передавать содержимое этих конфиденциальных файлов.

Файл web.config всегда должен присутствовать в развертывании, правильно именованный и способный настроить сайт для нормального запуска. Никогда не удаляйте файл web.config из рабочего развертывания.

Преобразование web.config

Если вам нужно преобразовать web.config при публикации (например, задать переменные среды на основе конфигурации, профиля или среды), см. статью Преобразование web.config.

Конфигурация IIS

ОС Windows Server

Включите роль сервера Веб-сервер (IIS) и настройте службы роли.

1. В меню Управление запустите мастер Добавить роли и компоненты или в окне Диспетчер серверов щелкните соответствующую ссылку. На этапе Роли сервера установите флажок Веб-сервер (IIS).

   

2. После этапа выбора компонентов запускается этап выбора служб роли для веб-сервера (IIS). Выберите нужные службы роли IIS или оставьте службы по умолчанию.

   

   Проверка подлинности Windows (необязательный компонент)
   Чтобы включить проверку подлинности Windows, разверните такие узлы: Веб-сервер>Безопасность. Выберите компонент Проверка подлинности Windows. Дополнительные сведения см. в статьях Аутентификация Windows<windowsAuthentication> и Настройка аутентификации Windows в приложении ASP.NET Core.

   Протокол WebSocket (необязательный компонент)
   Протокол WebSocket поддерживается в ASP.NET Core начиная с версии 1.1. Чтобы включить протокол WebSocket, разверните такие узлы: Веб-сервер>Разработка приложений. Выберите компонент Протокол WebSocket. Дополнительные сведения см. в разделе Протокол WebSocket.

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

Операционные системы Windows для настольных компьютеров

Включите компоненты Консоль управления IIS и Службы Интернета.

1. Последовательно выберите Панель управления>Программы>Программы и компоненты>Включение или отключение компонентов Windows (в левой части экрана).

2. Разверните узел Службы IIS. Разверните узел Средства управления веб-сайтом.

3. Установите флажок Консоль управления IIS.

4. Установите флажок Службы Интернета.

5. В группе Службы Интернета оставьте компоненты по умолчанию или настройте компоненты IIS.

   Проверка подлинности Windows (необязательный компонент)
   Чтобы включить проверку подлинности Windows, разверните такие узлы: Службы Интернета>Безопасность. Выберите компонент Проверка подлинности Windows. Дополнительные сведения см. в статьях Аутентификация Windows<windowsAuthentication> и Настройка аутентификации Windows в приложении ASP.NET Core.

   Протокол WebSocket (необязательный компонент)
   Протокол WebSocket поддерживается в ASP.NET Core начиная с версии 1.1. Чтобы включить протокол WebSocket, разверните такие узлы: Службы Интернета>Компоненты разработки приложений. Выберите компонент Протокол WebSocket. Дополнительные сведения см. в разделе Протокол WebSocket.

6. Если во время установки IIS потребуется перезагрузка, перезагрузите систему.

Установка пакета размещения .NET Core

Установите пакет размещения .NET Core в размещающей системе. В составе пакета устанавливаются среда выполнения .NET Core, библиотека .NET Core и модуль ASP.NET Core. Модуль позволяет запускать приложения ASP.NET Core под управлением IIS.

Загрузка

1. Перейдите на страницу загрузки .NET Core.
2. Выберите требуемую версию .NET Core.
3. В столбце Запуск приложений — среда выполнения найдите строку, содержащую нужную версию среды выполнения .NET Core.
4. Скачайте установщик по ссылке Hosting Bundle (Пакет размещения).

Установка пакета размещения .NET Core

1. Запустите установщик на сервере. При запуске установщика из командной оболочки администратора доступны следующие параметры:

   • OPT_NO_ANCM=1: пропустите установку модуля ASP.NET Core.
   • OPT_NO_RUNTIME=1: пропустить установку среды выполнения .NET Core. Используется, когда на сервере размещаются только автономные развертывания.
   • OPT_NO_SHAREDFX=1: пропустите установку ASP.NET Shared Framework (среда выполнения ASP.NET). Используется, когда на сервере размещаются только автономные развертывания.
   • OPT_NO_X86=1: пропустить установку сред выполнения x86. Этот параметр следует использовать, если вы наверняка не будете размещать 32-разрядные приложения. Если есть хоть малейшая возможность, что в будущем придется размещать и 32-разрядные, и 64-разрядные приложения, не указывайте этот параметр и установите обе среды выполнения.
   • OPT_NO_SHARED_CONFIG_CHECK=1 — отключение проверки использования общей конфигурации IIS, если файл общей конфигурации (applicationHost.config) находится на том же компьютере, что и установка IIS. Доступен только для пакетных установщиков размещения ASP.NET Core 2.2 или более поздней версии. Дополнительные сведения см. в разделе Модуль ASP.NET Core для IIS.

2. Перезапустите систему или выполните в командной оболочке следующие команды:

   net stop was /y
   net start w3svc
   

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

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

ASP.NET Core наследует поведение наката для выпусков исправлений пакетов общей платформы. Когда приложения, размещенные в службах IIS, перезапускаются вместе с IIS, они загружаются с последними выпусками исправлений связанных пакетов при получении первого запроса. Если службы IIS не перезапускаются, приложения перезапускаются и демонстрируют поведение наката, когда их рабочие процессы перезапускается и они получают первый запрос.

Установка веб-развертывания при публикации с помощью Visual Studio

При развертывании приложений на серверах с помощью веб-развертывания установите на сервере последнюю версию веб-развертывания. Чтобы установить веб-развертывание, используйте установщик веб-платформы (WebPI) или загрузки IIS: веб-развертывание. Предпочтительный метод — использовать WebPI. WebPI обеспечивает автономную установку и настройку поставщиков размещения.

Создание сайта IIS

1. В размещающей системе создайте папку, в которой будут храниться файлы и папки опубликованного приложения. На следующем этапе путь к папке предоставляется IIS как физический путь к приложению. Дополнительные сведения о папке развертывания и структуре файлов приложения см. в статье Структура каталогов ASP.NET Core.

2. В окне диспетчера IIS на панели Подключения разверните узел сервера. Щелкните правой кнопкой мыши папку Сайты. В контекстном меню выберите пункт Добавить веб-сайт.

3. Укажите имя в поле Имя сайта и задайте значение в поле Физический путь для созданной папки развертывания приложения. Укажите конфигурацию привязки и нажмите кнопку ОК, чтобы создать веб-сайт.

   

   Предупреждение

   Не используйте привязки с подстановочными знаками (http://*:80/ и http://+:80) на верхнем уровне. Это может создать уязвимость и поставить ваше приложение под угрозу. Сюда относятся и строгие, и нестрогие подстановочные знаки. Вместо этого используйте имена узлов в явном виде. Привязки с подстановочными знаками на уровне дочерних доменов (например *.mysub.com) не создают таких угроз безопасности, если вы полностью контролируете родительский домен (в отличие от варианта *.com, создающего уязвимость). Дополнительные сведения см. в разделе RFC 9110: семантика HTTP (раздел 7.2: host и :authority).

4. Разверните узел сервера и выберите Пулы приложений.

5. Щелкните правой кнопкой мыши пул приложений сайта и в контекстном меню выберите пункт Основные параметры.

6. В окне Изменение пула приложений задайте для параметра Версия среды CLR .NET значение Без управляемого кода.

   

   ASP.NET Core выполняется в отдельном процессе и управляет средой выполнения. ASP.NET Core не зависит от загрузки среды CLR для ПК (.NET CLR) — для размещения приложения в рабочем процессе запускается CoreCLR для .NET Core. Задавать для параметра Версия среды CLR .NET значение Без управляемого кода необязательно, но рекомендуется.

7. ASP.NET Core 2.2 или более поздней версии: для 64-разрядного (x64) автономного развертывания, в котором используется модель размещения в процессе, отключите пул приложений для 32-разрядных (x86) процессов.

   На боковой панели Действия в разделе Пулы приложений диспетчера IIS выберите Задать значения по умолчанию для пула приложений или Дополнительные параметры. Найдите пункт Включить 32-разрядные приложения и задайте значение False. Этот параметр не влияет на приложения, развернутые для размещения вне процесса.

8. Убедитесь, что модель identity процесса имеет соответствующие разрешения.

   Если по умолчанию identity пул приложений (модельIdentity> обработки) изменяется с ApplicationPoolIdentity на другойidentity, убедитесь, что у нового identity есть необходимые разрешения для доступа к папке приложения, базе данных и другим необходимым ресурсам. Например, пулу приложений требуются права на чтение и запись в папках, в которых приложение считывает и записывает файлы.

Настройка проверки подлинности Windows (необязательный этап)
См. статью Configure Windows authentication in an ASP.NET Core app (Настройка проверки подлинности Windows в приложении ASP.NET Core).

Развертывание приложения

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

Веб-развертывание с помощью Visual Studio

Сведения о создании профиля публикации для веб-развертывания см. в статье Профили публикации Visual Studio для развертывания приложений ASP.NET Core. Если поставщик услуг размещения предоставляет профиль публикации или позволяет его создать, скачайте этот профиль и импортируйте его с помощью диалогового окна Публикация в Visual Studio:

Веб-развертывание вне Visual Studio

Веб-развертывание можно также использовать вне Visual Studio с помощью командной строки. Дополнительные сведения см. в статье Средство веб-развертывания.

Альтернативы веб-развертыванию

Переместить приложение в размещающую систему можно несколькими способами: с помощью копирования вручную, Xcopy, Robocopy или PowerShell.

Дополнительные сведения о развертывании ASP.NET Core в службах IIS см. в разделе Ресурсы развертывания для администраторов IIS.

Открытие веб-сайта в браузере

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

В приведенном ниже примере сайт привязан к имени узла IIS www.mysite.com в порте 80. Запрос отправляется по адресу http://www.mysite.com:

Заблокированные файлы развертывания

Во время выполнения приложения файлы в папке развертывания блокируются. Заблокированные файлы невозможно перезаписать во время развертывания. Чтобы снять блокировку с файлов в развертывании, остановите пул приложений с помощью одного из следующих методов:

• Запустите веб-развертывание и добавьте ссылку на Microsoft.NET.Sdk.Web в файл проекта. Файл app_offline.htm помещается в корневой каталог веб-приложения. Когда файл присутствует, модуль ядра ASP.NET корректно завершает работу приложения и обслуживает app_offline.htm файл во время развертывания. Дополнительные сведения см. в разделе Справочник по конфигурации модуля ASP.NET Core.

• Вручную остановите пул приложений в диспетчере служб IIS на сервере.

• Используйте PowerShell для удаления app_offline.htm (требуется PowerShell 5 или более поздней версии):

  $pathToApp = 'PATH_TO_APP'
  
  # Stop the AppPool
  New-Item -Path $pathToApp app_offline.htm
  
  # Provide script commands here to deploy the app
  
  # Restart the AppPool
  Remove-Item -Path $pathToApp app_offline.htm
  
  

Защита данных

Стек защиты данных ASP.NET Core используют несколько ПО промежуточного слоя ASP.NET Core, включая ПО, которое применяется для аутентификации. Даже если API-интерфейсы защиты данных не вызываются из пользовательского кода, защиту данных следует настроить для создания постоянного хранилища криптографических ключей. Это можно сделать с помощью скрипта развертывания или в пользовательском коде. Если защита данных не настроена, ключи хранятся в памяти и удаляются при перезапуске приложения.

Если набор ключей хранится в памяти, при перезапуске приложения происходит следующее:

• Все токены аутентификации, использующие файлы cookie, становятся недействительными.
• При выполнении следующего запроса пользователю требуется выполнить вход снова.
• Все данные, защищенные с помощью набора ключей, больше не могут быть расшифрованы. Это могут быть токены CSRF и файлы cookie временных данных ASP.NET Core MVC.

Чтобы настроить защиту данных в службах IIS для хранения набора ключей, воспользуйтесь одним из следующих методов:

• Создание раздела реестра для защиты данных.

  Ключи защиты данных, используемые приложениями ASP.NET Core, хранятся во внешнем для приложений реестре. Чтобы хранить эти ключи для определенного приложения, нужно создать разделы реестра для пула приложений.

  При автономной установке служб IIS, не поддерживающей веб-ферму, можно выполнить скрипт PowerShell Provision-AutoGenKeys.ps1 для защиты данных применительно к каждому пулу приложений, в который входит приложение ASP.NET Core. Этот скрипт создает раздел в реестре HKLM, который будет доступен только для учетной записи рабочего процесса пула приложений, к которому относится соответствующее приложение. Ключи шифруются rest с помощью DPAPI с ключом на уровне компьютера.

  В случаях, когда используется веб-ферма, в приложении можно настроить UNC-путь, по которому это приложение будет хранить набор ключей для защиты данных. По умолчанию ключи защиты данных не шифруются. Разрешения на доступ к файлам в сетевой папке должны быть предоставлены только учетной записи Windows, с помощью которой выполняется приложение. Сертификат X509 можно использовать для защиты ключей.rest Рассмотрите возможность реализации механизма, позволяющего пользователям отправлять сертификаты: поместить сертификаты в хранилище доверенных сертификатов пользователя и обеспечивать их доступность на всех компьютерах, где выполняется приложение. Дополнительные сведения см. в разделе Настройка защиты данных в ASP.NET Core.

• Настройка пула приложений IIS для загрузки профиля пользователя.

  Этот параметр находится на странице Дополнительные параметры пула приложений в разделе Модель процесса. Задайте для параметра Загрузить профиль пользователя значение True. Если задать значение True, ключи будут храниться в каталоге профиля пользователя и защищаться с помощью API защиты данных и ключа на уровне учетной записи пользователя. Ключи хранятся в папке %LOCALAPPDATA%/ASP.NET/DataProtection-Keys.

  Также необходимо включить атрибут setProfileEnvironment пула приложений. Значение setProfileEnvironment по умолчанию — true. В некоторых сценариях (например, в ОС Windows) для параметра setProfileEnvironment установлено значение false. Если ключи не хранятся в каталоге профиля пользователя:

  1. Перейдите к папке %windir%/system32/inetsrv/config.
  2. Откройте файл applicationHost.config.
  3. Найдите элемент <system.applicationHost><applicationPools><applicationPoolDefaults><processModel>.
  4. Убедитесь, что атрибут setProfileEnvironment отсутствует и установлено значение по умолчанию true, или же явно задайте для атрибута значение true.

• Использование файловой системы в качестве хранилища набора ключей.

  Измените код приложения так, чтобы в качестве хранилища набора ключей использовалась файловая система. Для защиты набора ключей используйте доверенный сертификат X509. Если сертификат — самозаверяющий, поместите его в доверенное корневое хранилище.

  При использовании служб IIS в веб-ферме:

  • используйте общую папку, которая доступна всем компьютерам;
  • разверните сертификат X509 на каждом компьютере; настройте защиту данных в коде.

• Настройка политики защиты данных на уровне компьютера.

  Система защиты данных обеспечивает ограниченную поддержку задания политики по умолчанию на уровне компьютера для всех приложений, использующих интерфейсы API защиты данных. Дополнительные сведения см. в статье Защита данных в ASP.NET Core.

Виртуальные каталоги

Виртуальные каталоги IIS не поддерживаются в приложениях ASP.NET Core. Приложение может размещаться как вложенное.

Вложенные приложения

Приложение ASP.NET Core можно разместить как вложенное приложение IIS. Путь к вложенному приложению становится частью URL-адреса главного приложения.

Вложенное приложение не должно включать модуль ASP.NET Core в качестве обработчика. Если модуль добавляется в качестве обработчика в файл web.config дочернего приложения, при попытке работы с этим приложением выводится ошибка 500.19 (внутренняя ошибка сервера) с указанием некорректного файла конфигурации.

Вот пример опубликованного файла web.config для дочернего приложения ASP.NET Core:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <system.webServer>
    <aspNetCore processPath="dotnet" 
      arguments=".\MyApp.dll" 
      stdoutLogEnabled="false" 
      stdoutLogFile=".\logs\stdout" />
  </system.webServer>
</configuration>

Размещая вложенное приложение не на основе ASP.NET Core в приложении ASP.NET Core, явным образом удалите унаследованный обработчик из файла web.config вложенного приложения.

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <system.webServer>
    <handlers>
      <remove name="aspNetCore" />
    </handlers>
    <aspNetCore processPath="dotnet" 
      arguments=".\MyApp.dll" 
      stdoutLogEnabled="false" 
      stdoutLogFile=".\logs\stdout" />
  </system.webServer>
</configuration>

В ссылках на статический ресурс во вложенном приложении следует использовать нотацию ~/. Такая нотация активирует вспомогательную функцию тега для добавления свойства pathbase вложенного приложения в начало отображаемой относительной ссылки. Для вложенного приложения с путем /subapp_path ссылка на изображение src="~/image.png" отображается как src="/subapp_path/image.png". ПО промежуточного слоя для обработки статических файлов в главном приложении не обрабатывает такой запрос статического файла. Запрос обрабатывается соответствующим ПО вложенного приложения.

Если атрибуту src статического ресурса присваивается абсолютный путь (например, src="/image.png"), ссылка отображается без свойства pathbase вложенного приложения. ПО промежуточного слоя для обработки статических файлов в главном приложении пытается найти ресурс в корневом веб-каталоге главного приложения, что приводит к ошибке 404 — Not Found (не найдено), кроме случаев, когда статический ресурс доступен из главного приложения.

Для размещения приложения ASP.NET Core в качестве приложения, вложенного в другое приложение ASP.NET Core, сделайте следующее:

1. Создайте пул приложений для вложенного приложения. Установите для параметра Версия среды CLR .NET значение Без управляемого кода, так как для размещения приложения в рабочем процессе запускается CoreCLR для .NET Core, а не среда CRL для настольных ПК (.NET CLR).

2. Добавьте корневой веб-сайт в диспетчере служб IIS с вложенным приложением в папке внутри корневого веб-сайта.

3. Щелкните правой кнопкой мыши папку вложенного приложения в диспетчере служб IIS и выберите Преобразовать в приложение.

4. В диалоговом окне Добавление приложения нажмите кнопку Выбрать, чтобы назначить созданный пул приложений вложенному приложению. Нажмите ОК.

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

Дополнительные сведения о внутрипроцессной модели размещения и настройке модуля ASP.NET Core см. в статье Модуль ASP.NET Core (ANCM) для IIS.

Настройка служб IIS с помощью файла web.config

Конфигурация IIS зависит от <system.webServer> раздела web.config для сценариев IIS, предназначенных для работы приложений ASP.NET Core с помощью модуля ASP.NET Core. Например, конфигурация IIS работает для динамического сжатия. Если в службах IIS на уровне сервера настроено динамическое сжатие, элемент <urlCompression> в файле web.config приложения может отключить это сжатие для приложения ASP.NET Core.

Дополнительные сведения см. в следующих разделах:

• Справочник по настройке для <system.webServer>
• модуль ASP.NET Core (ANCM) для IIS
• Модули IIS с ASP.NET Core

Сведения о настройке переменных среды для отдельных приложений, выполняющихся в изолированных пулах приложений (такая возможность поддерживается в службах IIS начиная с версии 10.0), см. в справочной документации по службам IIS, в частности в разделе AppCmd.exe статьи Environment Variables <environmentVariables> (Переменные среды ).

Разделы, которые не используются ASP.NET Core

Разделы конфигурации приложений ASP.NET 4.x в файле web.config не используются для конфигурации приложений ASP.NET Core.

• <system.web>
• <appSettings>
• <connectionStrings>
• <location>

Для настройки приложений ASP.NET Core используются другие поставщики конфигураций. Дополнительные сведения см. в статье Конфигурация.

Пулы приложений

При размещении на сервере множества веб-сайтов рекомендуем изолировать приложения друг от друга, запуская каждое из них в собственном пуле. В диалоговом окне Добавить веб-сайт служб IIS такая конфигурация задана по умолчанию. Если указано Имя сайта, оно автоматически переносится в текстовое поле Пул приложений. При добавлении веб-сайта создается пул приложений с именем сайта.

Identity пула приложений

Учетная запись пула identity приложений позволяет приложению работать под уникальной учетной записью, не создавая домены или локальные учетные записи и управляя ими. В службах IIS начиная с версии 8.0 рабочий процесс администратора IIS (WAS) создает виртуальную учетную запись с именем нового пула приложений и по умолчанию выполняет рабочие процессы пула приложений с помощью этой учетной записи. В консоли управления IIS в окне Дополнительные параметры пула приложений для Identity необходимо выбрать ApplicationPoolIdentity.

Процесс управления IIS создает в системе безопасности Windows безопасный идентификатор с именем пула приложений. С помощью этого identityсредства можно защитить ресурсы. Однако это identity не реальная учетная запись пользователя и не отображается в консоли управления пользователями Windows.

Если рабочему процессу IIS требуется предоставить доступ к приложению с повышенными правами, измените список управления доступом (ACL) для каталога, содержащего приложение.

1. Откройте проводник и перейдите к каталогу.

2. Щелкните каталог правой кнопкой мыши и выберите пункт Свойства.

3. На вкладке Безопасность нажмите кнопку Изменить, а затем — кнопку Добавить.

4. Нажмите кнопку Размещение и выберите систему.

5. В поле Введите имена выбираемых объектов введите IIS AppPool\<имя_пула_приложений>. Нажмите кнопку Проверить имена. В случае с DefaultAppPool проверьте имена с помощью IIS AppPool\DefaultAppPool. После нажатия кнопки Проверить имена в области имен объектов отобразится значение DefaultAppPool. Вручную ввести имя пула приложений в области имен объектов нельзя. При поиске имени объекта используйте формат IIS AppPool\<имя_пула_приложений>.

   

6. Нажмите ОК.

   

7. Разрешения на чтение и выполнение должны быть предоставлены по умолчанию. При необходимости предоставьте дополнительные разрешения.

Кроме того, доступ можно предоставить через командную строку, используя средство ICACLS. В случае с DefaultAppPool выполняется такая команда:

ICACLS C:\sites\MyWebApp /grant "IIS AppPool\DefaultAppPool":F

Дополнительные сведения об ICACLS см. здесь.

Поддержка HTTP/2

HTTP/2 поддерживается для внепроцессных развертываний, которые удовлетворяют следующим базовым требованиям:

• Windows Server 2016 / Windows 10 или более поздних версий; IIS 10 или более поздней версии
• Общедоступные подключения пограничного сервера используют HTTP/2, однако обратное прокси-соединение с Kestrel сервером использует HTTP / 1.1.
• Целевая платформа: неприменимо к развертываниям вне процесса, так как IIS полностью обрабатывает подключение HTTP/2.
• Подключение TLS 1.2 или более поздней версии

Если установлено подключение HTTP/2, HttpRequest.Protocol возвращает HTTP/1.1.

Протокол HTTP/2 по умолчанию включен. Если не удается установить подключение HTTP/2, применяется резервный вариант HTTP/1.1. Дополнительные сведения о настройке HTTP/2 для развертываний IIS см. в статье об HTTP/2 в IIS.

Предварительные запросы CORS

Этот раздел относится только к приложениям ASP.NET Core, предназначенным для .NET Framework.

Для приложения ASP.NET Core, предназначенного для .NET Framework, параметры OPTIONS не передаются в приложение по умолчанию в службах IIS. Сведения о настройке обработчиков IIS приложения в web.config для передачи запросов OPTIONS см. в статье "Включение запросов между источниками" в веб-API ASP.NET 2. Как РАБОТАЕТ CORS.

Ресурсы развертывания для администраторов IIS

• Документация по службам IIS
• Начало работы с диспетчером IIS в IIS
• Развертывание приложений .NET Core
• модуль ASP.NET Core (ANCM) для IIS
• структура каталогов ASP.NET Core
• Модули IIS с ASP.NET Core
• Устранение неполадок ASP.NET Core в службе приложение Azure и IIS
• Устранение распространенных неполадок в Службе приложений Azure и службах IIS с помощью ASP.NET Core

Дополнительные ресурсы

• Публикация приложения ASP.NET Core в IIS
• Устранение неполадок и отладка проектов ASP.NET Core
• Общие сведения об ASP.NET Core
• Официальный веб-сайт Microsoft IIS
• Библиотека технического содержимого по Windows Server
• HTTP/2 on IIS (HTTP/2 в IIS)
• Преобразование web.config