IIS не может запустить основной сайт ASP.NET - ошибка HTTP 502.5
У нас есть машина с Windows 2012 R2. У меня был существующий сайт ASP.NET Core, на котором работал рабочий опубликованный сайт ASP.NET Core.
Однако, когда я снова опубликовал сайт сегодня, через месяц после внесения изменений, я больше не могу получить доступ к сайту и получить следующую ошибку в своем браузере.
Ошибка HTTP 502.5 - сбой процесса
Для получения дополнительной информации посетите: http://go.microsoft.com/fwlink/?LinkID=808681
Если я захожу на сервер и нажимаю exe в моем развернутом каталоге, он открывает командную строку и показывает мой сайт на порту 5000. Если я захожу на сайт по http://localhost:5000/, он работает отлично, поэтому проблема заключается в том, чтобы сделать с IIS, а не сам сайт.
Если я войду на сервер, я вижу следующее в Windows EventViewer
Приложению 'MACHINE/WEBROOT/APPHOST/DEFAULT WEB SITE/MySite' с физическим корнем 'D:\Sites\MySite\' не удалось запустить процесс с командной строкой '"%LAUNCHER_PATH%" %LAUNCHER_ARGS%', ErrorCode = '0x80070002: 0.
Когда я захожу по ссылке в сообщении об ошибке браузера, там упоминается переустановка пакета.net Core Hosting, что я и сделал. Однако сообщение об ошибке в браузере совпадает.
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<system.webServer>
<handlers>
<add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModule" resourceType="Unspecified" />
</handlers>
<aspNetCore requestTimeout="02:00:00" processPath="%LAUNCHER_PATH%" arguments="%LAUNCHER_ARGS%" stdoutLogEnabled="true" stdoutLogFile=".\logs\stdout" forwardWindowsAuthToken="false" />
</system.webServer>
</configuration>
Когда я смотрю на папку журнала приложения, файл stdout создается каждый раз, когда он пытается получить доступ к этому сайту, но каждый раз он имеет размер 0 КБ и пустое содержимое.
Почему IIS отказывается работать внезапно там, где оно работало ранее, но приложение работает, если я получаю прямой доступ к скомпилированному exe-файлу?
21 ответ
Ваша проблема в плохом файле web.config:
<aspNetCore requestTimeout="02:00:00"
processPath="%LAUNCHER_PATH%"
arguments="%LAUNCHER_ARGS%"
stdoutLogEnabled="true"
stdoutLogFile=".\logs\stdout"
forwardWindowsAuthToken="false" />
Путь%LAUNCHER_PATH% не существует в вашей системе, он даже недопустим. Это должно быть что-то вроде:
<aspNetCore requestTimeout="02:00:00"
processPath=".\yourAppName.exe"
arguments="somePossibleArgument"
stdoutLogEnabled="true"
stdoutLogFile=".\logs\stdout"
forwardWindowsAuthToken="false" />
Обратите внимание, что файл web.config полностью игнорируется, если приложение запускается из командной строки, поэтому вы не получаете сообщение об ошибке.
У меня была такая же проблема, моя проблема была в том, что IIS не смог получить путь к dotnet. Мне удалось это исправить, указав путь к dotnet.exe
<configuration>
<system.webServer>
<handlers>
<add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModule" resourceType="Unspecified" />
</handlers>
<aspNetCore processPath="C:\Program Files\dotnet\dotnet.exe" arguments=".\your-project.dll" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout"/>
</system.webServer>
</configuration>
Моя проблема заключалась в том, что процесс не запустился из-за неверной escape-последовательности в моем appsettings.json файл.
Я использую dotnet для запуска опубликованных веб-API ASPNET Core 2. Проблема была обнаружена путем открытия командной строки и перехода в каталог, где находятся файлы сайта. Оказавшись там, я запустил команду:
dotnet mySite.dll
(Измените mySite.dll на основную dll вашего приложения. Также убедитесь, что правильная версия пакета.NET Core Windows Server Hosting уже установлена).
Нажав Enter, он сразу же упал, давая точную обратную связь в окне консоли о том, что было не так. Это отличный способ помочь определить ваши ошибки при запуске, если у вас возникли похожие проблемы.
Проблема: Когда я развертываю веб-API ядра сети asp, для processPath устанавливается точка. Приложение не запускается, и средство просмотра событий показывает вышеуказанную ошибку.
Решение:
Идентификатор пула приложений должен быть настроен для загрузки профиля.
Перейдите к: Пул приложений -> NetCore (ваш пул) -> Расширенные настройки -> Загрузить профиль пользователя ----> Установите для этого параметра значение true
Я подтвердил, что переключение на ложное воссоздание ошибки и возвращение к истинному разрешило ее.
У меня была похожая проблема. Я просто следовал инструкциям по устранению неполадок: Check the system event log for error messages и нашел следующее из Event Viewer, Application 'MACHINE/WEBROOT/APPHOST/[MyFolder]' with physical root 'C:\inetpub\wwwroot\[MyFolder]\' failed to start process with commandline 'dotnet .\MyApp.dll', ErrorCode = '0x80004005 : 80008083.
Я тогда перезапустил dotnet .\MyApp.dll из терминала и получил ответ:
It was not possible to find any compatible framework version
The specified framework 'Microsoft.AspNetCore.App', version '2.1.1' was not found.
- Check application dependencies and target a framework version installed at:
\
- Alternatively, install the framework version '2.1.1'.
Таким образом, причина та же, что ответил jv_, у вас просто не установлена совместимая версия фреймворка. Я закончил тем, что использовал "Автономный" Режим Развертывания, и он работал.
Это полностью свело меня с ума, учитывая, что я перепробовал все возможные исправления, найденные в Интернете, но у меня ничего не получалось. Пока я не узнал, проблема заключалась в том, что в названии моего проекта было пробел: App WebAPI.dll. Поэтому, когда "dotnet .\App WebAPI.dll" пытается выполнить его, происходит сбой, потому что он действительно пытается выполнить "dotnet .\App" и забывает вторую часть после пробела. Переименование моего решения и имен проектов для удаления пробелов (AppWebAPI) решило мою проблему. Я надеюсь, что это исправление экономит время людей, пытающихся выяснить проблему.
Я столкнулся с этой же проблемой, когда развернул свое приложение. Было несколько проблем с моей стороны:)
Я прошел эту страницу очень тщательно: ASP.NET Core: публикация в IIS
Во-первых, у меня не были установлены все части пакета .NET Core Windows Server Hosting. Я закончил тем, что делал независимое развертывание вместо независимой. У нас много приложений, и мы не хотим / нуждаемся в каждом из них в своих версиях ядра.net. Там будет слишком много версий.net на коробке.
Кроме того, обратите внимание, что если ваши администраторы выполнили какие-либо обновления / обновления на сервере, они могли бы испортить вашу установку ASP.NET Core (см. Раздел " Устранение неполадок при публикации в IIS для ASP.NET)".
Затем мне пришлось исправить мой web.config... вот мой рабочий опубликованный web.config: я не публиковал как *.exe, я сделал *.dll (обратите внимание на значение моих аргументов). Кроме того, мой processPath установлен в "dotnet".
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<system.webServer>
<handlers>
<add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModule" resourceType="Unspecified" />
</handlers>
<aspNetCore processPath="dotnet" arguments=".\DT.Web.dll" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" forwardWindowsAuthToken="false" />
</system.webServer>
</configuration>
Кроме того, убедитесь, что все параметры вашего project.json совместимы с вашей серверной средой (см. Раздел " ASP.NET Core: публикация в IIS ")
Вот копия моего project.json, если это может помочь
{
"version": "2.0.1.0",
"dependencies": {
"DT.Common": "2.*",
"DT.Configuration": "2.*",
"DT.Services": "2.*",
"DT.Web.ViewModels": "2.*",
"Microsoft.ApplicationInsights.AspNetCore": "1.0.2",
"Microsoft.AspNetCore.Authentication": "1.1.0",
"Microsoft.AspNetCore.Authentication.Cookies": "1.1.0",
"Microsoft.AspNetCore.Authentication.OpenIdConnect": "1.1.0",
"Microsoft.AspNetCore.Diagnostics": "1.1.0",
"Microsoft.AspNetCore.Mvc": "1.1.0",
"Microsoft.AspNetCore.Razor.Tools": {
"version": "1.1.0-preview4-final",
"type": "build"
},
"Microsoft.AspNetCore.Routing": "1.1.0",
"Microsoft.AspNetCore.Server.IISIntegration": "1.1.0",
"Microsoft.AspNetCore.Server.IISIntegration.Tools": {
"version": "1.1.0-preview4-final",
"type": "build"
},
"Microsoft.AspNetCore.Server.Kestrel": "1.1.0",
"Microsoft.AspNetCore.Server.Kestrel.Https": "1.1.0",
"Microsoft.AspNetCore.Session": "1.0.0",
"Microsoft.AspNetCore.StaticFiles": "1.1.0",
"Microsoft.Extensions.Caching.SqlServer": "1.0.0",
"Microsoft.Extensions.Configuration.Abstractions": "1.1.0",
"Microsoft.Extensions.Configuration.FileExtensions": "1.1.0",
"Microsoft.Extensions.Configuration.Json": "1.1.0",
"Microsoft.Extensions.Logging.Console": "1.1.0",
"Microsoft.Extensions.Logging.Debug": "1.1.0",
"Microsoft.Extensions.Options.ConfigurationExtensions": "1.0.0",
"Microsoft.Graph": "1.1.1",
"Microsoft.IdentityModel.Clients.ActiveDirectory": "3.13.6"
},
"tools": {
"Microsoft.AspNetCore.Server.IISIntegration.Tools": "1.1.0-preview4-final",
"Microsoft.AspNetCore.Razor.Tools": {
"version": "1.1.0-preview4-final",
"imports": "portable-net45+win8+dotnet5.6"
},
"Microsoft.Extensions.Caching.SqlConfig.Tools": "1.1.0-preview4-final"
},
"frameworks": {
"netcoreapp1.1": {
"imports": [
"dotnet5.6",
"portable-net45+win8"
],
"dependencies": {
"Microsoft.NETCore.App": {
"version": "1.1.0",
"type": "platform"
}
}
}
},
"buildOptions": {
"emitEntryPoint": true,
"preserveCompilationContext": true
},
"runtimeOptions": {
"configProperties": {
"System.GC.Server": true
}
},
"publishOptions": {
"include": [
"wwwroot",
"views/**/*.cshtml",
"appsettings.json",
"appsettings.*.json",
"web.config"
]
},
"scripts": {
"prepublish": [ "bower install", "gulp buildprod" ],
"postpublish": [ "dotnet publish-iis --publish-folder %publish:OutputPath% --framework %publish:FullTargetFramework%" ]
}
}
У меня была та же проблема с Visual Studio, преобразовавшим файл web.config и изменив processPath и аргументы. Как указано на сайте Microsoft, вы можете добавить исключение в файл project.csproj:
<PropertyGroup>
<IsTransformWebConfigDisabled>true</IsTransformWebConfigDisabled>
</PropertyGroup>
Это позаботилось о моей проблеме с изменением значения пути при публикации, но у меня все еще остается проблема с Visual Studio, изменяющей его самостоятельно при отладке.
Мой проект работал нормально в разработке, но после веб-развертывания / публикации в производство он бросал 502.5 Process Failure,
Причина оказалась в том, что я обновился с помощью Microsoft.AspNetCore.All 2.0.5 в 2.0.6, Работал нормально после возврата версии обратно.
Для меня решение было просто установить .Net Core 2.2 SDK и это сработало.
В моем случае это
HTTP Error 502.5 произошло, когда я клонировал несколько довольно старых репозиториев git, которые содержали веб-проекты, ориентированные на .NET Core 1.1 ... некоторое время назад я удалил среду выполнения .NET Core 1.1 со своего компьютера с Windows.
Я пошел, загрузил среду выполнения и снова установил ее. Получил последнюю версию с этой страницы - 1.1.13:
https://dotnet.microsoft.com/download/dotnet/thank-you/runtime-1.1.13-windows-x64-installer
Теперь все хорошо. Вернуться к работе. :-)
Отвечая некоторым пользователям, которые упомянули проблемы с именем или путем к приложению:
Я столкнулся с этой проблемой в образце проекта «WebApp-OpenIDConnect-DotNet» ( https://github.com/AzureADQuickStarts/WebApp-OpenIdConnect-DotNet), который отлично работал в IIS Express, но не в IIS.
Оказывается, если погрузиться в исходный код .NET на https://github.com/dotnet/aspnetcore/blob/master/src/Servers/IIS/AspNetCoreModuleV2/CommonLib/HostFxrResolver.cpp , потому что имя сборки заканчивалось на «-DotNet.exe» (или, может быть, просто DotNet.exe), предполагалось, что он должен работать как отдельное приложение. Отсюда и жалоба на недостающие аргументы. Я долго рвал на себе волосы, прежде чем поиск строки ошибки в журнале событий Windows привел меня к исходному файлу.
Изменение имени сборки, чтобы оно не заканчивалось на «-DotNet.exe», решило проблему для меня.
Я должен добавить, что на самом деле я получал ошибку 500.30, а не 500.5. Но эта ветка максимально приблизила меня к решению проблемы, поэтому я публикую здесь свое решение.
Надеюсь, это кому-то поможет.
Ребята, мой сайт тоже работал нормально, и внезапно он начал показывать эту ошибку. Мой сайт был размещен на go daddy . Их техническая команда также не смогла выяснить точную причину. Я перепробовал все приведенные выше комментарии, ни один из них не работал нормально. Итак, потратив много времени, мы решили
Я сохранил processPath, как и processPath="dotnet" в моем web.config. Перед тем, как показать эту ошибку, я внес некоторые изменения в свой файл appsettings.json, чтобы обновить строку подключения. Я отредактировал его с помощью filezilla (используя опцию просмотра / редактирования) на моем локальном компьютере. Я думаю, он мог быть поврежден, что также вызвало эту проблему.
Итак, что я сделал, я снова опубликовал свой проект локально, и я сделал обновления строки подключения локально в моем appsettings.json и развернул эти последние изменения в godaddy. После этого развертывания мой сайт снова начал появляться.
Когда у команды, над которой я работал, возникла эта проблема, кто-то просто создал проект с помощью Visual Studio и заархивировал папку bin.
Вам нужно запустить команду dotnet publish, чтобы задачи msbuild правильно построили ваш файл web.config. Он должен заменить переменные%LAUNCHER_PATH%"и"%LAUNCHER_ARGS%.
Для меня через некоторое время я понял, что проблема связана с одним из свойств в
appsettings.json
файл.
У меня есть свойство с именем Version. Формат такой:
"Version": "1.0.6",
На сервере наша служба поддержки не рассматривала этот формат и это было так:
"Version": 1.0.6,
и IIS столкнулся с ошибкой 502,5.
Я видел журнал событий приложений, и он мне помог.
Я столкнулся с той же проблемой, и ничего из этой темы для меня не помогло. Поэтому я заглянул в средство просмотра событий Windows и обнаружил, что у пользователя недостаточно разрешений для создания / изменения базы данных, поскольку я использовал миграцию основной базы данных EF. Исправление авторизации решило эту проблему.
Поэтому я бы посоветовал просмотреть события вашего приложения и, надеюсь, вы найдете там основную причину своей ошибки.
Я получил аналогичный ответ со следующими записями системного журнала средства просмотра событий:
Приложению '/LM/W3SVC/8/ROOT' с физическим корнем '' не удалось запустить процесс с командной строкой 'dotnet .<имя_сборки>.dll' с несколькими повторными попытками. Не удалось выполнить привязку к порту «2118». Первые 30 КБ символов захваченных журналов stdout и stderr из нескольких попыток: [конец сообщения]
После сравнения установленных версий с работающим сервером, также развернутым в то же время, я обнаружил, что системные переменные обновлялись некорректно.
Я добавил следующие пути к переменной окружения «Путь»:
- C:\Program Files\dotnet\
- C:\Program Files (x86)\dotnet\
И он сразу начал работать.
Я хотел иметь возможность запускать мой.Net Core API из IIS из моего каталога разработки, не борясь с файлом web.config. Visual Studio управляет web.config на основе настроек профиля проекта. Вам просто нужно добавить профиль IIS в начало отладки, чтобы VS знал, что делать с вашим web.config. Инструкции здесь:
Теперь я могу просто немного кодировать, компилировать и обновлять свой браузер, не дожидаясь запуска браузера и не теряя строку запроса каждый раз. Нажатие на Отладку автоматически присоединяет VS к IIS для отладки, что означает, что больше не нужно вручную подключать отладчик к w3wp, что меня раздражало целую вечность. Отлично!
Для справки, VS динамически меняет мой web.config на это:
<aspNetCore processPath="bin\IISSupport\VSIISExeLauncher.exe" arguments="-argFile IISExeLauncherArgs.txt" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout">
<environmentVariables />
Но я бы не стал жестко кодировать это в web.config, просто позволил VS управлять этим.:)
Я решаю эту проблему, добавляя processPath="C:\Program Files\dotnet\dotnet.exe" в файл web.confing.
ИЛИ ЖЕ
Запустите команду dotnet --version и, если вы получаете сообщение типа «dotnet», не является внутренней или внешней командой, исполняемой программой или пакетным файлом.
dotnet.exe находится в
C:\Program Files\dotnet> Если вы используете командную строку и получаете сообщение о том, что «dotnet» не распознается как внутренняя или внешняя команда, исполняемая программа или пакетный файл», сначала проверьте указанный выше путь. Если вы нашли указанный выше путь затем просто скопируйте его и установите в качестве переменной среды вашего ПК.
Шаги:
Откройте панель управления>Система и безопасность>Система.
Нажмите «Дополнительные параметры системы».
В расширенном разделе нажмите «Переменные среды».
В системных переменных выберите путь и отредактируйте
После точки с запятой напишите «C:\Program Files\dotnet».
Нажмите кнопку «ОК» до конца.
теперь, чтобы проверить, работает ли он на нет. Просто откройте командную строку и введите
У меня была та же проблема, за исключением того, что я обновил Visual Studio в своей среде разработки, и на сервере требовалось обновление среды выполнения.NetCore. После того, как я обновил время выполнения на сервере, мне было хорошо идти снова.
Я думаю, что моя неопытность с обновлением VS 2017 была моей проблемой;-)
Иногда это происходит из-за имени пространства в сборке или имени пространства имен.
Старайтесь избегать пространства.
Перейти к проекту >>[Проект] Свойства >> {вкладка приложения} Изменить имя сборки и имя пространства имен по умолчанию, удалить пробелы!