Развертывание ASP.NET Core на Windows с IIS

Note

Это не последняя версия этой статьи. В текущей версии см. версию .NET 10 этой статьи.

Warning

Эта версия ASP.NET Core больше не поддерживается. Дополнительные сведения см. в политике поддержки .NET и .NET Core. В текущей версии см. версию .NET 10 этой статьи.

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

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

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

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

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

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

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

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

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

Дополнительные сведения об установке модуля ASP.NET Core или установке различных версий см. в разделе "Установка пакета размещения .NET".

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

Get started

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

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

Configuration

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

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

Перекрещенная переработка

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Модуль ASP.NET Core:

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

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

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

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

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

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

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

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

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

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

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

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

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

Запросы поступают из Интернета в драйвер HTTP.sys в режиме ядра.
Драйвер направляет запросы к службам IIS на настроенный порт веб-сайта. Обычно это порт 80 (HTTP) или порт 443 (HTTPS).
Модуль пересылает запросы к 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;
});

Option	Default	Setting
`AutomaticAuthentication`	`true`	Если значение — `true`, сервер IIS задает свойство `HttpContext.User`, использующее проверку подлинности Windows. Если `false`, сервер предоставляет удостоверение только для `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;
});

Option	Default	Setting
`AutomaticAuthentication`	`true`	Если `true`, ПО промежуточного слоя для интеграции IIS устанавливает `HttpContext.User`, который аутентифицирован с помощью проверки подлинности Windows. Если `false`, промежуточное ПО предоставляет удостоверение только для `HttpContext.User` и реагирует на вызовы при явном запросе от `AuthenticationScheme`. Для функционирования `AutomaticAuthentication` необходимо включить проверку подлинности Windows в IIS. Дополнительные сведения см. в статье Windows Authentication.
`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. Целевой объект_TransformWebConfig MSBuild обрабатывает создание, преобразование и публикацию web.config файла при публикации проекта. Этот целевой объект присутствует в целевых веб-пакетах 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>

При отключении Web 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) и настройте службы роли.

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

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

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

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

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

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

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

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

Консоль управления IIS и службы Всемирной паутины выбраны в окне

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

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

Important

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

Если пакет размещения установлен после установки 64-разрядной версии .NET, пакеты SDK могут отсутствовать (Пакеты SDK для .NET не обнаружены). Информацию о решении проблемы см. в статье Устранение неполадок и отладка проектов ASP.NET Core.

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

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

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

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

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

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

Warning

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

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

Запустите установщик на сервере. При запуске установщика из командной оболочки администратора доступны следующие параметры:
- OPT_NO_ANCM=1: пропустите установку модуля ASP.NET Core.
- OPT_NO_RUNTIME=1: пропустить установку среды выполнения .NET. Используется, когда на сервере размещаются только автономные развертывания.
- OPT_NO_SHAREDFX=1: Пропустить установку ASP.NET Shared Framework (среда выполнения ASP.NET). Используется, когда на сервере размещаются только автономные развертывания (SCD).
- 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.
Перезапуск служб IIS позволит обнаружить внесенные установщиком изменения в системном пути, который является переменной среды. Чтобы перезапустить веб-сервер, завершите работу службы активации Windows (WAS), а затем перезапустите службу веб-публикаций (W3SVC). Перезапустите систему или выполните в командной оболочке с повышенными привилегиями следующие команды:
```
net stop was /y
net start w3svc
```

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

net stop was /y
net start w3svc

Note

Сведения об общей конфигурации IIS см. в разделе Модуль ASP.NET Core с общей конфигурацией IIS.

Установите Web Deploy при публикации с помощью Visual Studio

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

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

В размещающей системе создайте папку, в которой будут храниться файлы и папки опубликованного приложения. На следующем этапе путь к папке предоставляется IIS как физический путь к приложению. Дополнительные сведения о папке развертывания и структуре файлов приложения см. в статье Структура каталогов ASP.NET Core.
В окне диспетчера IIS на панели Подключения разверните узел сервера. Щелкните правой кнопкой мыши папку Сайты. В контекстном меню выберите пункт Добавить веб-сайт.
Укажите имя в поле Имя сайта и задайте значение в поле Физический путь для созданной папки развертывания приложения. Укажите конфигурацию привязки и нажмите кнопку ОК, чтобы создать веб-сайт.

Warning

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

ASP.NET Core выполняется в отдельном процессе и управляет средой выполнения. Для ASP.NET Core не требуется загрузка десктопной версии CLR (.NET CLR). Базовая среда CLR (CoreCLR) для .NET загружается для размещения приложения в рабочем процессе. Задавать для параметра Версия среды CLR .NET значение Без управляемого кода необязательно, но рекомендуется.
ASP.NET Core 2.2 или более поздней версии:
- Для 32-разрядного (x86) автономного развертывания, созданного с использованием 32-разрядного SDK и использующего модель размещения в процессе, включите Пул приложений для 32-разрядной архитектуры. В диспетчере IIS перейдите в раздел Пулы приложений на боковой панели Подключения. Выберите пул приложений приложения. На боковой панели Действия выберите Дополнительные параметры. Установите для параметра Включить 32-разрядные приложения значение True.
- для 64-разрядного (x64) автономного развертывания, в котором используется модель размещения в процессе, отключите пул приложений для 32-разрядных (x86) процессов. В диспетчере IIS перейдите в раздел Пулы приложений на боковой панели Подключения. Выберите пул приложений приложения. На боковой панели Действия выберите Дополнительные параметры. Установите для параметра Включить 32-разрядные приложения значение False.
Проверьте, что идентификатор модели процесса обладает соответствующими разрешениями.

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

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

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

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

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

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

Диалоговое окно

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

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

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

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

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

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

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

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

Браузер Microsoft Edge загрузил начальную страницу IIS.

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

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

Запустите веб-развертывание и добавьте ссылку на 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 TempData.

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

Создание ключей реестра защиты данных.

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

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

В случаях, когда используется веб-ферма, в приложении можно настроить UNC-путь, по которому это приложение будет хранить набор ключей для защиты данных. По умолчанию ключи защиты данных не шифруются. Разрешения на доступ к файлам в сетевой папке должны быть предоставлены только учетной записи Windows, с помощью которой выполняется приложение. Сертификат X509 можно использовать для защиты неактивных ключей. Рассмотрите возможность реализации механизма, позволяющего пользователям отправлять сертификаты: поместить сертификаты в хранилище доверенных сертификатов пользователя и обеспечивать их доступность на всех компьютерах, где выполняется приложение. Дополнительные сведения см. в разделе Настройка защиты данных в 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. Если сертификат — самоподписанный, поместите его в доверенное корневое хранилище.

При использовании служб Internet Information Services (IIS) в среде веб-фермы:
- используйте общую папку, которая доступна всем компьютерам;
- разверните сертификат X509 на каждом компьютере; настройте защиту данных в коде.
Настройка политики защиты данных на уровне компьютера.

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

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

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

Sub-applications

Приложение ASP.NET Core можно разместить как подприложение IIS (sub-app). Путь к вложенному приложению становится частью 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, сделайте следующее:

Создайте пул приложений для вложенного приложения. Задайте версию .NET CLR на No Managed Code, так как основная среда CLR (CoreCLR) для .NET запускается для размещения приложения в рабочем процессе, а не десктопной среды CLR (.NET CLR).
Добавьте корневой сайт в диспетчере IIS с вложенным приложением в папке под корневым сайтом.
Щелкните правой кнопкой мыши папку вложенного приложения в диспетчере служб IIS и выберите Преобразовать в приложение.
В диалоговом окне Добавление приложения используйте кнопку Выбрать для пула приложений, чтобы назначить пул приложений, созданный вами для вложенного приложения. Нажмите ОК.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Диалоговое окно дополнительных параметров для пула приложений

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

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

Откройте проводник и перейдите к каталогу.
Щелкните каталог правой кнопкой мыши и выберите пункт Свойства.
На вкладке Безопасность нажмите кнопку Изменить, а затем — кнопку Добавить.
Нажмите кнопку Размещение и выберите систему.
Введите IIS AppPool\{APP POOL NAME}, где заполнитель {APP POOL NAME} представляет собой имя пула приложения, в области Введите имена объектов для выбора. Нажмите кнопку Проверить имена. В случае с DefaultAppPool проверьте имена с помощью IIS AppPool\DefaultAppPool. После нажатия кнопки Проверить имена в области имен объектов отобразится значение DefaultAppPool. Вручную ввести имя пула приложений в области имен объектов нельзя. При проверке имени объекта используйте формат IIS AppPool\{APP POOL NAME}, где заполнитель {APP POOL NAME} представляет собой имя пула приложения.
Нажмите ОК.
Разрешения на чтение и выполнение должны быть предоставлены по умолчанию. При необходимости предоставьте дополнительные разрешения.

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

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

Дополнительные сведения см. в статье icacls .

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

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

In-process
- Windows Server 2016 / Windows 10 или более поздних версий; IIS 10 или более поздней версии
- Подключение TLS 1.2 или более поздней версии
Out-of-process
- 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 (Cross-Origin Resource Sharing) в веб-API ASP.NET 2: как это работает.

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

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

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

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

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

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

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

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

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

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

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

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

При использовании диспетчера 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:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Модуль 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 или KestrelListen не требуются. При вызове 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

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

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

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

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

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

файл web.config

В файле web.config содержится конфигурация модуля ASP.NET Core. Целевой объект MSBuild (_TransformWebConfig) обрабатывает создание, преобразование и публикацию файлаweb.config при публикации проекта. Этот целевой объект присутствует в целевых веб-пакетах 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 и аргументы. Дополнительные сведения см. в разделе Модуль 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) и настройте службы роли.

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

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

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

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

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

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

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

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

Компоненты

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

Important

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

Download

Перейдите на страницу скачивания .NET .
Выберите нужную версию .NET.
В столбце "Запуск приложений — среда выполнения " найдите нужную строку версии среды выполнения .NET.
Скачайте установщик по ссылке Hosting Bundle.

Warning

Некоторые установщики содержат релизные версии, которые больше не поддерживаются Microsoft. Дополнительные сведения см. в разделе Политика поддержки.

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

Запустите установщик на сервере. При запуске установщика из командной оболочки администратора доступны следующие параметры:
- OPT_NO_ANCM=1: пропустите установку модуля ASP.NET Core.
- OPT_NO_RUNTIME=1: пропустить установку среды выполнения .NET. Используется, когда на сервере размещаются только автономные развертывания (SCD).
- OPT_NO_SHAREDFX=1: Пропустите установку Общего фреймворка ASP.NET (время выполнения ASP.NET). Используется, когда на сервере размещаются только автономные развертывания (Self-Contained Deployments).
- 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.
Перезапустите систему или выполните в командной оболочке следующие команды:
```
net stop was /y
net start w3svc
```
Перезапуск служб IIS позволит обнаружить внесенные установщиком изменения в системном пути, который является переменной среды.

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

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

Note

Сведения об общей конфигурации IIS см. в разделе Модуль ASP.NET Core с общей конфигурацией IIS.

Установите Web Deploy при публикации с помощью Visual Studio

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

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

В размещающей системе создайте папку, в которой будут храниться файлы и папки опубликованного приложения. На следующем этапе путь к папке предоставляется IIS как физический путь к приложению. Дополнительные сведения о папке развертывания и структуре файлов приложения см. в статье Структура каталогов ASP.NET Core.
В окне диспетчера IIS на панели Подключения разверните узел сервера. Щелкните правой кнопкой мыши папку Сайты. В контекстном меню выберите пункт Добавить веб-сайт.
Укажите имя в поле Имя сайта и задайте значение в поле Физический путь для созданной папки развертывания приложения. Укажите конфигурацию привязки и нажмите кнопку ОК, чтобы создать веб-сайт.

Warning

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

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

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

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

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

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

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

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

Диалоговое окно

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

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

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

Браузер Microsoft Edge загрузил стартовую страницу IIS.

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

Запустите веб-развертывание и добавьте ссылку на 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

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

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

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

Создание ключей реестра для защиты данных.

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

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

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

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

Sub-applications

Приложение 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>

В ссылках на статические ресурсы внутри подприложения следует использовать нотацию с тильдой и слэшем (~/). Тильда-слэш нотация активирует Tag Helper, чтобы добавить 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, сделайте следующее:

Создайте пул приложений для суб-приложения. Задайте версию .NET CLR на No Managed Code, так как основная среда CLR (CoreCLR) для .NET запускается для размещения приложения в рабочем процессе, а не десктопной среды CLR (.NET CLR).
Добавьте корневой сайт в диспетчере IIS с вложенным приложением в папке под корневым сайтом.
Щелкните правой кнопкой мыши папку вложенного приложения в диспетчере служб IIS и выберите Преобразовать в приложение.
В диалоговом окне Добавление приложения используйте кнопку Выбрать для пула приложений, чтобы выбрать пул, который вы создали для подприложения. Нажмите ОК.

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

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

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

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

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

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

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

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

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

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

Диалоговое окно дополнительных параметров для пула приложений

Откройте проводник и перейдите к каталогу.
Щелкните каталог правой кнопкой мыши и выберите пункт Свойства.
На вкладке Безопасность нажмите кнопку Изменить, а затем — кнопку Добавить.
Нажмите кнопку Размещение и выберите систему.
Введите IIS AppPool\имя_пула_приложений в области Введите имена объектов для выбора. Нажмите кнопку Проверить имена. В случае с DefaultAppPool проверьте имена с помощью IIS AppPool\DefaultAppPool. После нажатия кнопки Проверить имена в области имен объектов отобразится значение DefaultAppPool. Вручную ввести имя пула приложений в области имен объектов нельзя. При поиске имени объекта используйте формат IIS AppPool\<имя_пула_приложений>.
Нажмите ОК.
Разрешения на чтение и выполнение должны быть предоставлены по умолчанию. При необходимости предоставьте дополнительные разрешения.

Кроме того, доступ можно предоставить через командную строку, используя средство 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.

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

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

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

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

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

Обратная связь

Были ли сведения на этой странице полезными?

Last updated on 2026-04-23

Развертывание ASP.NET Core на Windows с IIS

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

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

Get started

Configuration

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

Перекрещенная переработка

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

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

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

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

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

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

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

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

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

Параметры IIS

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

Файл web.config

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

Изменить web.config

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

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

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

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

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

Установите Web Deploy при публикации с помощью Visual Studio

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

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

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

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

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

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

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

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

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

Sub-applications

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Параметры IIS

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

файл web.config

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

Изменить web.config

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

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

Download

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

Установите Web Deploy при публикации с помощью Visual Studio

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

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

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

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

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

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

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

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

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

Sub-applications

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

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

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

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

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

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

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

Файл `web.config`

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