Вопрос или проблема
Я пытаюсь развернуть свое приложение .NET Framework MVC на VM с использованием Azure Pipelines.
Актуальный код:
- task: IISWebAppManagementOnMachineGroup@0
inputs:
IISDeploymentType: 'IISWebsite'
ActionIISWebsite: 'CreateOrUpdateWebsite'
WebsiteName: 'MySite'
WebsitePhysicalPath: 'D:/MySite/WebUi'
WebsitePhysicalPathAuth: 'WebsiteUserPassThrough'
CreateOrUpdateAppPoolForWebsite: true
AppPoolNameForWebsite: 'DefaultAppPool'
DotNetVersionForWebsite: 'No Managed Code'
PipeLineModeForWebsite: 'Integrated'
AppPoolIdentityForWebsite: 'ApplicationPoolIdentity'
AddBinding: true
Bindings: |
{
bindings:[
{
"protocol":"http",
"ipAddress":"",
"hostname":"",
"port":"802",
"sslThumbprint":"",
"sniFlag":false
}
]
}
- task: IISWebAppDeploymentOnMachineGroup@0
inputs:
WebSiteName: 'MySite'
Package: '$(Pipeline.Workspace)/drop/WebUi/WebUi.zip'
Результат состоит в том, что в IIS Manager я вижу, что новый сайт был создан в папке “Сайты”, но когда я нажимаю “Просмотр *:802 (http)”, я получаю ошибку по умолчанию IIS 404 (HTTP Error 404.0 – Not Found),
с деталями:
Подробная информация об ошибке:
Модуль IIS Web Core
Уведомление MapRequestHandler
Обработчик StaticFile
Код ошибки 0x80070002
Запрашиваемый URL http://localhost:802/
Физический путь D:/MySite/WebUi
Метод входа Анонимный
Пользователь входа Анонимный
Хотя, когда я изменил пул приложений этого сайта с Unmanaged на v4.0, я получаю стандартную ошибку веб-браузера:
Эта страница localhost не может быть найдена
Для веб-адреса: http://localhost:802/ веб-страница не найдена
HTTP ERROR 404
а не подробную ошибку IIS, как когда пул приложений является unmanaged.
Основные настройки (как физический путь) в порядке, указывая правильное место на диске, которое содержит папки: bin, Content, fonts, Scripts, Views, и файлы: favicon, global.asax, packages.config, web.config, так что все выглядит нормально.
Что я проверил:
- Версия ASP.NET и другие функции Windows на VM
- Привилегии для папки WebUi в IIS
- Изменение с
DotNetVersionForWebsite: 'No Managed Code'
наDotNetVersionForWebsite: 'v4.0'
и изменение пула приложений на v4.0 не дает никакой разницы.
Это приложение ранее было обновлено (на другой VM) просто с помощью ctrl+c и ctrl+v содержимого папки WebUi, так что само приложение в порядке.
То, что я обнаружил, это то, что на VM, где приложение работает нормально, после перехода к базовому URL (например, servername.internal.com) происходит автоматическая переадресация на servername.internal.com/WebUi, а в моем проблемном случае переадресации не происходит.
Я не знаю, что еще мне проверить. Может быть, есть способ получить настройки IIS с другой VM (где приложение работает нормально), чтобы сравнить их с настройками IIS проблемной VM?
Ответ или решение
Проблема развертывания приложения .NET MVC через Azure Pipelines на IIS
Введение
При развертывании приложения .NET Framework MVC на виртуальной машине через Azure Pipelines может возникнуть ряд проблем, особенно при использовании задачи IISWebAppManagementOnMachineGroup
. В этом ответе мы рассмотрим возможные причины ошибок, которые могут возникнуть, а также предложим шаги для их устранения.
Описание проблемы
Ваша задача развертывания настроена правильно. По логам видно, что веб-сайт создается, однако при попытке доступа к нему через браузер возникает ошибка 404. При этом важным моментом является то, что правильная структура папок и файлов на диске подтверждает, что приложение должным образом загружено.
Анализ ошибок
-
Ошибка HTTP 404 (Не найдено): Эта ошибка может указывать на то, что сервер не может найти запрашиваемый ресурс. Исходя из предоставленной информации, стоит изучить следующие моменты:
-
Путь физического расположения (Physical Path): Проверьте, что у вас действительно есть доступ к папке
D:/MySite/WebUi
, и что там есть файлindex.html
илиdefault.aspx
(в зависимости от конфигурации вашего приложения). Если главного файла нет, IIS не сможет отобразить содержимое. -
Настройки IIS: Убедитесь, что в настройках IIS вашего приложения указаны правильные разрешения для подключения к папкам, а также другие параметры, необходимые для запуска вашего приложения.
-
-
Настройки пула приложений (App Pool):
-
Для приложений на .NET Framework, особенно для ASP.NET приложений, рекомендуется использовать пул приложений, который соответствует версии .NET. Убедитесь, что AppPoolNameForWebsite действительно указывает на
DefaultAppPool
и что для него установлена версия .NET v4.0. -
Понять, что использование
DotNetVersionForWebsite: 'No Managed Code'
может быть проблематичным, так как это указывает на отсутствие управления для ASP.NET. Попробуйте установить эту опцию вv4.0
и убедитесь, что ваш App Pool поддерживает это.
-
Дополнительные шаги для устранения неполадок
-
Проверка перенаправления:
- Ваша заметка о том, что на работающей виртуальной машине происходит автоматическое перенаправление на
servername.internal.com/WebUi
, является ключевым моментом. Убедитесь, что в вашем web.config файле на проблемной машине корректно настроены правила перенаправления.
- Ваша заметка о том, что на работающей виртуальной машине происходит автоматическое перенаправление на
-
Настройка прав доступа:
- Проверьте, что у IIS есть достаточные права для доступа к физической папке
D:/MySite/WebUi
, в частности, для группыIIS_IUSRS
, которая может не иметь необходимых прав.
- Проверьте, что у IIS есть достаточные права для доступа к физической папке
-
Сравнение настроек IIS:
- Вы можете экспортировать настройки IIS с работающей машины, используя команды PowerShell:
Export-WebConfiguration -PSPath "IIS:\Sites\MySite" -DestinationPath "C:\IISConfigBackup.zip"
- На проблемной машине вы можете импортировать эти настройки для сравнения.
- Вы можете экспортировать настройки IIS с работающей машины, используя команды PowerShell:
Заключение
В итоге, для решения проблемы с развертыванием вашего .NET Framework MVC приложения необходимо провести тщательную проверку настроек IIS, прав доступа и конфигураций пулов приложений. Следуя вышеизложенным шагам, вы сможете диагностировать и решить вашу проблему разбора перед развертыванием приложения в вашем окружении Azure.
Если проблема сохраняется, рекомендуется обратиться к системному администратору для подробной проверки настроек сервера или использовать логи IIS для дальнейшей диагностики.