#iis #.net-core #application-pool
#iis #.net-ядро #пул приложений
Вопрос:
Я столкнулся с проблемой с сервером IIS 10.0, Windows Server 2016. Я использую InstallShield для установки веб-приложения. Он использует новое приложение .NET CORE, которое использует неуправляемый пул приложений. Пул приложений успешно создан и назначен установщиком. Однако, если установлено какое-либо другое веб-приложение, система создает новый пул управляемых приложений с тем же именем, что и у исходного, с префиксом «ASP.NET v4.0», который убивает приложение .NET Core.
Есть идеи, как я могу предотвратить создание этого дополнительного пула приложений?
Обновить:
Обратите внимание, что когда ASP.NET версия 4.0 установлена для веб-сайтов или приложений, функция IIS InstallShield вызывает версию .NET 4.0 aspnet_regiis.exe. При запуске этого инструмента все существующие пулы приложений, которые не настроены на использование .NET 4.0, дублируются и переименовываются в «ASP.NET существующее имя v4.0», и для их версий .NET framework установлено значение v4.0.
На самом деле, это происходит. По умолчанию, когда я устанавливаю свой веб-интерфейс DotNet Core, тип пула приложений по умолчанию — «Без управляемого кода». Поэтому, когда я устанавливаю другое веб-приложение, IIS создает дополнительный пул приложений.
Но, если я изменю пул приложений dotnet core webapi на «ASP.NET V4», другое приложение не создаст дополнительный пул приложений.
Итак, еще один вопрос: «Не следует ли мне использовать тип пула приложений «Без управляемого кода» для DotNet Core WebAPI?
Комментарии:
1. каждый раз, когда создается новый сайт, ему необходимо назначить существующий пул приложений или создать для него новый. Установщик, похоже, ошибается, если он создает пул, который влияет на существующий сайт.
2. @PeterHahndorf Нет, это не ошибка установщика. Что-то еще. Я обновил свой вопрос.
3. Я не знаю InstallShield, но, насколько мне известно, iis автоматически не создает пулы приложений. Кроме того, вам необходимо установить для версии .NET CLR значение Без управляемого кода, поскольку Базовая среда выполнения общего языка (CoreCLR) для .NET Core загружается для размещения приложения в рабочем процессе, а не в среде CLR рабочего стола (.NET CLR).