Расширенная настройка модуля ASP.NET Core и служб IIS

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

Изменение размера стека

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

Настройте размер управляемого стека, задав для параметра stackSize значение в байтах в файле web.config. Размер по умолчанию — 1 048 576 байт (1 МБ). В следующем примере размер стека изменяется на 2 МБ (2 097 152 байт).

<aspNetCore processPath="dotnet"
    arguments=".\MyApp.dll"
    stdoutLogEnabled="false"
    stdoutLogFile="\\?\%home%\LogFiles\stdout"
    hostingModel="inprocess">
  <handlerSettings>
    <handlerSetting name="stackSize" value="2097152" />
  </handlerSettings>
</aspNetCore>

Запрет поворота в конфигурации

Этот disallowRotationOnConfigChange параметр предназначен для голубых и зеленых сценариев, в которых изменение глобальной конфигурации не должно привести ко всем сайтам для перезапуска. Если этот флаг имеет значение true, изменения, относящиеся к самому сайту, могут привести к его перезапуску. Например, сайт перезапускается, если его web.config изменяется или что-то изменение, соответствующее пути сайта с точки зрения IIS. Но общее изменение в applicationHost.config не приведет к перезапуску приложения. В следующем примере этот параметр имеет значение true:

<aspNetCore processPath="dotnet"
    arguments=".\MyApp.dll"
    stdoutLogEnabled="false"
    stdoutLogFile="\\?\%home%\LogFiles\stdout"
    hostingModel="inprocess">
  <handlerSettings>
    <handlerSetting name="disallowRotationOnConfigChange" value="true" />
  </handlerSettings>
</aspNetCore>

Этот параметр соответствует API ApplicationPoolRecycling.DisallowRotationOnConfigChange

Конфигурация прокси-сервера использует протокол HTTP и токен связывания

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

Прокси-сервер, созданный между модулем ASP.NET Core и Kestrel, использует протокол HTTP. Отсутствует риск перехвата трафика между модулем и Kestrel из расположения за пределами сервера.

Токен связывания гарантирует, что полученные Kestrel запросы были переданы через прокси-сервер IIS, а не из какого-либо другого источника. Этот токен создается и задается модулем в переменную среды (ASPNETCORE_TOKEN). Он также задается в заголовке (MS-ASPNETCORE-TOKEN) каждого запроса, переданного через прокси-сервер. ПО промежуточного слоя IIS проверяет каждый получаемый запрос, чтобы убедиться, что заголовок с токеном связывания соответствует значению переменной среды. Если значения токена не совпадают, запрос заносится в журнал и отклоняется. Переменная среды с токеном связывания и трафик между модулем и Kestrel недоступны из расположения за пределами сервера. Не зная значение токена связывания, злоумышленник не может отправлять запросы, обходящие проверку в ПО промежуточного слоя IIS.

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

Установщик основных модулей ASP.NET запускается с привилегиями учетной TrustedInstaller записи. Так как учетная запись локальной системы не имеет разрешения на изменение пути к общей папке, используемого общей конфигурацией IIS, установщик выдает ошибку отказа в доступе при попытке настроить параметры модуля в файле в applicationHost.config общей папке.

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

dotnet-hosting-{VERSION}.exe OPT_NO_SHARED_CONFIG_CHECK=1

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

1. Отключите общую конфигурацию IIS.
2. Запустите установщик.
3. Экспортируйте обновленный файл applicationHost.config в общую папку.
4. Повторно включите общую конфигурацию IIS.

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

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

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

Конфигурация 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.

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

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

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

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

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

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

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

Примечание.

Razor компоненты (.razor) не должны использовать нотацию tilde-slash. Дополнительные сведения см. в документации по базовому Blazor пути приложения.

Если атрибуту 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 на каждое приложение по умолчанию задан один пул приложений. Если указано Имя сайта, оно автоматически переносится в текстовое поле Пул приложений. При добавлении веб-сайта создается пул приложений с именем сайта.

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

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

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

ICACLS C:\sites\MyWebApp /grant "IIS AppPool\DefaultAppPool:(OI)(CI)RX"

Дополнительные сведения об 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 (x86/amd64):

• %windir%\System32\inetsrv\aspnetcore.dll

• %windir%\SysWOW64\inetsrv\aspnetcore.dll

• %ProgramFiles%\IIS\Asp.Net Core Module\V2\aspnetcorev2.dll

• %ProgramFiles(x86)%\IIS\Asp.Net Core Module\V2\aspnetcorev2.dll

IIS Express (x86/amd64):

• %ProgramFiles%\IIS Express\aspnetcore.dll

• %ProgramFiles(x86)%\IIS Express\aspnetcore.dll

• %ProgramFiles%\IIS Express\Asp.Net Core Module\V2\aspnetcorev2.dll

• %ProgramFiles(x86)%\IIS Express\Asp.Net Core Module\V2\aspnetcorev2.dll

Схема

IIS

• %windir%\System32\inetsrv\config\schema\aspnetcore_schema.xml

• %windir%\System32\inetsrv\config\schema\aspnetcore_schema_v2.xml

IIS Express

• %ProgramFiles%\IIS Express\config\schema\aspnetcore_schema.xml

• %ProgramFiles%\IIS Express\config\schema\aspnetcore_schema_v2.xml

Настройка

IIS

• %windir%\System32\inetsrv\config\applicationHost.config

IIS Express

• Visual Studio: {APPLICATION ROOT}\.vs\config\applicationHost.config

• CLI iisexpress.exe: %USERPROFILE%\Documents\IISExpress\config\applicationhost.config

Файлы можно найти, выполнив поиск aspnetcore в applicationHost.config файле.

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

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

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

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

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

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

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

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

Теневое копирование

Теневое копирование сборок приложений в модуль ASP.NET Core (ANCM) для IIS может быть удобнее для пользователя, чем остановка приложения путем развертывания автономного файла приложения.

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

Теневое копирование не предназначено для обеспечения развертывания с нулевым временем простоя, поэтому ожидается, что IIS все равно перезапустит приложение, а на некоторые запросы может вернуться ответ 503 Service Unavailable. Для исключения простоев рекомендуем использовать шаблон сине-зеленого развертывания или слоты развертывания Azure. Теневое копирование помогает свести к минимуму время простоя при развертывании, но не может полностью исключить его.

Теневое копирование включается путем настройки параметров обработчика ANCM в web.config:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <system.webServer>
    <handlers>
      <remove name="aspNetCore"/>
      <add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModuleV2" resourceType="Unspecified"/>
    </handlers>
    <aspNetCore processPath="%LAUNCHER_PATH%" arguments="%LAUNCHER_ARGS%" stdoutLogEnabled="false" stdoutLogFile=".logsstdout">
      <handlerSettings>
        <handlerSetting name="enableShadowCopy" value="true" />
        <!-- Ensure that the IIS ApplicationPool identity has permission to this directory -->
        <handlerSetting name="shadowCopyDirectory" value="../ShadowCopyDirectory/" />
      </handlerSettings>
    </aspNetCore>
  </system.webServer>
</configuration>