ASP.NET Core 1.0 при ошибке IIS 502.5

112

Я только что обновил свой сервер (Windows 2012R2) до .Net Core 1.0 RTMпакета хостинга Windows с предыдущего .Net Core 1.0 RC2. Мое приложение работает на моем компьютере без проблем, но сервер продолжает показывать:

HTTP Error 502.5 - Process Failure


Common causes of this issue:

The application process failed to start
The application process started but then stopped
The application process started but failed to listen on the configured port

Ранее он работал с версией RC2. Не знаю, что может пойти не так.

Это все, что говорит программа просмотра событий:

Failed to start process with the commandline 'dotnet .\MyWebApp.dll'. Error code = '0x80004005'.

Хуже всего то, что журналы приложений пусты! Я имею в виду, что файлы stdout_xxxxxxxxx.log полностью пусты и все имеют размер 0 байт.

Что я должен делать?? Как я могу узнать причину ошибки, если она не регистрируется?

Вахид Амири
источник
Возможно связаны? stackoverflow.com/questions/37362183/…
Брендан Грин
3
Как это связано? Код ошибки явно другой. Не говоря уже о том, что я сказал, что он работает на моем собственном ПК с IIS.
Вахид Амири
1
Во-первых, я сказал, что возможно связано, поскольку упоминает, что Failed to start process with commandline 'dotnet ./bin/Debug/netcoreapp1.0/WebApplication2.dll', Error Code = '0x80004005'.- та же командная строка и код ошибки, о которых вы сообщаете. Во-вторых, тот факт, что он работает на вашем компьютере, но не на удаленном, указывает на то, что на сервере что-то не так. Если бы вы могли подробнее рассказать о том, как приложение развертывается на сервере, это было бы полезно.
Брендан Грин
что вы имеете в виду, что ваше приложение работает на вашем компьютере ... вы имеете в виду, что у вас есть проект, развертываемый в iis? я ryt?
Vijunav Vastivch
1
@ VSG24 Вы видели этот раздел документа asp.net? При публикации в IIS он перечисляет распространенные ошибки и содержит несколько причин для ошибки 502.5.
Хамид Мосалла

Ответы:

112

Я смог исправить это, запустив

"C: \ Program Files \ dotnet \ dotnet.exe" "C: \ fullpath \ PROJECT.dll"

в командной строке, что дало мне гораздо более значимую ошибку:

«Указанный фреймворк 'Microsoft.NETCore.App', версия '1.0.1' не найден. - Проверьте зависимости приложений и выберите версию фреймворка, установленную по адресу: C: \ Program Files \ dotnet \ shared \ Microsoft.NETCore.App - Установлены следующие версии: 1.0.0 - Вы также можете установить версию фреймворка 1.0.1.

Как видите, на моем сервере была установлена ​​неправильная версия NET Core. Я смог запустить свое приложение после удаления предыдущей версии 1.0.0 и установки правильной версии 1.0.1.

hatsrumandcode
источник
2
Мне удалось использовать это, чтобы найти, что мне нужен установленный NodeJS ... поскольку он дает «гораздо более значимое сообщение».
Тим Харкер
Не могу сказать, сколько времени я потратил на это. Спасибо. Моя ошибка была связана с отсутствующим сертификатом. Почему я не могу получить эту ошибку каким-то разумным способом?
Sprague
4
Подскажите, пожалуйста, что это за команда? Что такое C: \ fullpath \ dotnet ?? Путь к вашему приложению, но что такое dotnet ? В папке проекта нет файла dotnet
Джереми Томпсон
9
@JeremyThompson - это путь к dotnet.exe, который обычно находится по адресу: C: \ Program Files \ dotnet \ dotnet.exe
hatsrumandcode
1
Я только что столкнулся с этой ошибкой после того, как обновление .NET CORE 2.1.3 исправило ее, установив правильный .NET SDK / среду выполнения.
Майк Бовенландер
68

У меня была такая же проблема, в моем случае это было недостаточное разрешение удостоверения пользователя моего пула приложений при публикации на странице IIS документа asp.net, для этой ошибки указана пара причин:

  • Если вы опубликовали автономные приложения, убедитесь , что вы не установили платформу buildOptionsдля того, project.jsonчто конфликтов с издательскими РИД. Например, не указывайте платформу x86 и публикуйте с RID win81-x64 ( dotnet publish -c Release -r win81-x64). Проект будет опубликован без предупреждений или ошибок, но завершится ошибкой с указанными выше исключениями, зарегистрированными на сервере.
  • Проверьте processPathатрибут <aspNetCore>элемента в web.config, чтобы убедиться, что он предназначен dotnetдля переносимого приложения или. \ My_application.exe для автономного приложения.
  • Для переносимого приложения он dotnet.exeможет быть недоступен через настройки PATH. Подтвердите, что C:\Program Files\dotnet\существует в настройках ПУТЬ системы.
  • Для переносимого приложения dotnet.exeможет быть недоступен для удостоверения пользователя пула приложений. Убедитесь, что удостоверение пользователя AppPool имеет доступ к C:\Program Files\dotnetкаталогу.
  • Убедитесь, что вы правильно указали промежуточное программное обеспечение интеграции IIS, вызвав .UseIISIntegration()метод приложения WebHostBuilder().
  • Если вы используете .UseUrls()метод расширения при самостоятельном размещении с помощью Kestrel, убедитесь, что он расположен перед .UseIISIntegration()методом расширения WebHostBuilder(). .UseIISIntegration()должен установить Urlдля обратного прокси при запуске Kestrel за IIS и не иметь переопределения его значения .UseUrls().

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

Хамид Мосалла
источник
1
Это тот ответ, который я искал !, в моем случае это тоже был пул приложений ....
Армандо Рамирес
3
Спасибо. В моем случае проблема заключалась в пути к dotnet. Найдено такие журналы в системном журнале событий: Failed to start process with commandline '"dotnet" .\PROJECT.dll', ErrorCode = '0x80070002'.
0x49D1
Я бы добавил еще одну причину: «Установщик не может получить распространяемый пакет VC ++», поскольку у моего сервера нет подключения к Интернету, он не может загрузить этот пакет ... Следовательно, вам нужно вручную загрузить его: связать и установить.
Пако Мендес
4
dotnetбыл на моем пути, но для его распознавания потребовался перезапуск сервера.
Дэнни Каллен
в моем случае я должен указать значение --runtime в команде публикации, если я предоставляю параметр --framework, в противном случае НЕ указывайте --framework, и по умолчанию он определяет время выполнения.
Gomes
66

Я получил это, работая с полной перезагрузкой IIS (я только что установил пакет хостинга).

Оказывается, просто нажать «Перезагрузить» в диспетчере IIS недостаточно. Мне просто нужно было открыть командную строку и набрать iisreset.

michael_hook
источник
Я также нажал зеленый значок корзины на корневом узле веб-сервера в пользовательском интерфейсе. Это решило эту проблему для меня в сочетании с пользовательскими настройками для пула приложенийLocalSystem
JP Hellemons
Спасибо, Майкл ... Это тоже решило мою проблему. Пару часов искал ответ. Спасибо!
birwin
2
Tx! Ваш ответ напомнил мне об этом из документов ms «Перезагрузите систему или выполните net stop was / y, за которым следует net start w3svc из командной строки, чтобы получить изменение в системном PATH». (после установки пакета .NET Core Windows Server Hosting)
Куинтон Смит,
Решил и мою проблему. Спасибо
Met-u
Работал у меня. Спасибо :)
Husnain Shabbir
11

Итак, у меня есть новый сервер, на этот раз Windows 2008R2, и мое приложение работает нормально.

Я не могу точно сказать, в чем проблема со старым сервером, но у меня есть одна идея.

Поскольку я ранее скомпилировал приложение без какой-либо платформы, оно дало мне dllверсию, которая работает только в том случае, если на целевом хосте установлен .Net Core Windows Hostingпакет. В моем случае он был установлен, и это было нормально .

После того, как приложение перестало работать, я решил скомпилировать его как консольное приложение со win7-x64средой выполнения. На этот раз, когда я запустил exeсвое приложение на сервере, он вылетел с ошибкой об отсутствующей dll:

The program can't start because api-ms-win-crt-runtime-l1-1-0.dll is missing

Эта dll принадлежит универсальной среде выполнения C, которая входит в распространяемый пакет Visual C ++ для Visual Studio 2015 .

Я пытался установить этот пакет (как x64, так и x86), но каждый раз он терпел неудачу (не знаю почему) на Windows Server 2012 R2.

Но когда я попытался установить их на новый сервер Windows Server 2008 R2, они установились успешно. Возможно, это было причиной этого, но до сих пор не могу сказать наверняка.

Вахид Амири
источник
5

У меня была такая же проблема при публикации веб-приложения. Если у кого-то все еще есть эта проблема, исправьте ее, изменив {AppName} .runtimeconfig.json

    {
  "runtimeOptions": {
    "framework": {
      "name": "Microsoft.NETCore.App",
      "version": "1.1.2"
    },
    "configProperties": {
      "System.GC.Server": true
    }
  }
}

Измените версию с «version»: «1.1.2» на «version»: «1.1.1», и все работает нормально.

NPO
источник
5

У меня такая же проблема.

Чтобы узнать его точный источник, я включил логин в файл web.config:

<aspNetCore processPath="dotnet" arguments=".\MyWebService.dll" stdoutLogEnabled="**true**" stdoutLogFile=".\logs\stdout" />

и создал подпапку журналов в корневой папке MyWebService.

После перезапуска IIS и попытки выполнить API я получил сообщение об ошибке и отсутствовала надлежащая Core Runtime. После загрузки установки DotNetCore.1.0.5_1.1.2-WindowsHosting ошибка исчезла.

Эдуард Силантьев
источник
3
ИМО, вы должны удалить звездочки с «истинного» значения, чтобы избежать путаницы.
AperioOculus
4

Была такая же проблема, и все решения не сработали. Нашел этот драгоценный камень и подумал, что пройду мимо, если он кому-то поможет. Установите на Server 2012 R2 с ошибкой отсутствия DLL, попробуйте переустановить VS C ++ 2015 и получите сообщение об ошибке. Исправление заключается в следующем:

Кажется, у файла C:\ProgramData\Package Cache\...\packages\Patch\x64\Windows8.1-KB2999226-x64.msuпроблемы с установкой. Откройте командную строку администратора и выполните:

c:
mkdir tmp
mkdir tmp\tmp
move "C:\ProgramData\Package Cache\...\packages\Patch\x64\Windows8.1-KB2999226-x64.msu" c:\tmp
expand -F:* c:\tmp\Windows8.1-KB2999226-x64.msu c:\tmp\tmp
dism /online /add-package /packagepath:c:\tmp\tmp\Windows8.1-KB2999226-x64.cab

ПРИМЕЧАНИЕ: замените "..." правильным именем папки. После этого переустановите пакет VS C ++ 2015.

Ли Харрис
источник
4

У меня была аналогичная проблема, и процитирую Шерлока Холмса: " Когда вы устранили невозможное, все, что остается, каким бы невероятным оно ни было, должно быть правдой? »

Я проверил, установлена ​​ли на сервере платформа .NET, на которую я нацелился, и оказалось, что это не так. Я установил 4.6.2 .NET Framework, и все заработало.

TheDoctor05
источник
4

У меня возникла эта проблема на рабочем сервере после того, как мой проект VS был автоматически обновлен до .NET Core 1.1.2.

Я просто установил ядро ​​среды выполнения 1.1.2 .net отсюда на свой рабочий сервер: https://www.microsoft.com/net/download/core#/runtime

Рикард Аскелоф
источник
Я столкнулся с той же проблемой, но с недавно выпущенным net core 2.0.6. Исправлено установкой net core SDK 2.0.6 на производственный сервер
dodbrian
4

РЕШЕНО. Я столкнулся с той же проблемой сегодня при развертывании в AZURE. . Затем я попробовал то же самое для локального IIS, получил ту же проблему. Поскольку я новичок в .net CORE, я боролся за несколько часов, прежде чем я действительно решил это.

В нашем решении после публикации в IIS я наблюдал за своим файлом web.confile, особенно под строкой <aspNetCore processPath="bin\IISSupport\VSIISExeLauncher.exe" arguments="-argFile IISExeLauncherArgs.txt" forwardWindowsAuthToken="false" stdoutLogEnabled="false" />

В нашей папке развертывания сгенерированный файл web.config выглядит так:<aspNetCore processPath="dotnet" arguments=".\Yodlee.dll -argFile IISExeLauncherArgs.txt" forwardWindowsAuthToken="false" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" />

Теперь ПОЖАЛУЙСТА, попробуйте изменить указанную выше конфигурацию в решении Visual Studio на<aspNetCore processPath="bin\IISSupport\VSIISExeLauncher.exe" forwardWindowsAuthToken="false" stdoutLogEnabled="false" />

В нашей новой папке развертывания сгенерированный файл web.config выглядит так:<aspNetCore processPath="dotnet" arguments=".\Yodlee.dll" forwardWindowsAuthToken="false" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" />

И это РЕШИТ мою проблему, надеюсь, это поможет.

Agni
источник
Привет, @Agni, у меня сработало, спасибо. Но каждый раз, когда я пытаюсь снова опубликовать проект в Azure, он перестраивается, и файл web.config автоматически возвращается к исходному с той частью, которая вызывает проблему: «-argFile IISExeLauncherArgs.txt». Вы нашли для этого решение? (Я использую asp.net core 2.0).
Родриго Пирес
1
в моем случае мне пришлось поменять processPath="dotnet"на processPath="C:\Program Files\dotnet\dotnet.exe". тогда это сработало.
vaheeds
3

У меня была такая же проблема, когда я обновил свою машину разработчика до Core 1.0.1, но забыл обновить сервер.

Алекс Дреско
источник
Для меня я переустановил SDK net core отсюда: microsoft.com/net/core#windows, тогда он сработал.
Jean
1
VS2017 теперь по умолчанию является .NET Core 1.1 - все удаленные серверы необходимо обновить перед публикацией обновленных проектов в IIS. Вы можете получить более полезное сообщение об ошибке («.NET core 1.1 не установлено»), но работаетdotnet .\YOURPROJDLL.dll
Coruscate5
3

Я получал ошибку HTTP 502.5 при попытке опубликовать свой .NET Core 2.0 API в AWS EB, и решил ее, добавив следующий код в .csproj:

  <PropertyGroup>
    <PublishWithAspNetCoreTargetManifest>false</PublishWithAspNetCoreTargetManifest>
  </PropertyGroup>
Матеус Ласерда
источник
2

У меня была такая же проблема. Я изменил удостоверение пула приложений на учетную запись сетевой службы. Затем я явно установил путь к dotnet.exe в web.config, чтобы приложение работало правильно, как сказал @danielyewright в своем комментарии на github . Он работает после установки пути.

Спасибо

вики
источник
2

В моем случае эта ошибка возникла из-за того, что я забыл обновить project.json с помощью:

"buildOptions": {
    "emitEntryPoint": true
  }
vinjenzo
источник
2

У меня была та же ошибка, о которой идет речь, с теми же проблемами, что описаны VSG24 в Предлагаемом ответе - неприятное сообщение об ошибке при вводе dotnet в CMD:

Программа не запускается из-за отсутствия api-ms-win-crt-runtime-l1-1-0.dll

Я решил эту проблему, установив вручную следующие 2 обновления на Windows Server 2012 R2 (а также необходимые предварительные условия и все другие связанные обновления - внимательно прочтите инструкции по установке на веб-сайте Microsoft):

  1. KB2919355
  2. KB2999226

Надеюсь, это кому-то поможет.

Йохан Фоли
источник
2

Я столкнулся с той же проблемой, когда пытался опубликовать отладочную версию своего веб-приложения. В этом наборе файлов нет файла web.configс нужным значением атрибутаprocessPath .

Я взял этот файл из Release версии, значение было присвоено пути к моему exe файлу.

<aspNetCore processPath=".\My.Web.App.exe" ... />
Барабас
источник
2

В моем случае проблема с установленной на сервере версией Net Core. Я просто устанавливаю ту же версию, что и на моей машине разработки, и все в порядке :-)

Соленая рыба
источник
2

Мне нужно было установить последнюю версию .NET Core, найденную здесь . Не нужно перезапускать сайт или сервер

Дэниел Грязный, Родной Мартин
источник
2

Я решил это, добавив «разрешение на редактирование» к приложению сайта, сопоставив его с физическим каталогом, а затем выбрав пользователя Windows, который мог бы иметь доступ к этой корневой папке. (частная сеть).

Антонин ГАВРЕЛЬ
источник
2

В моем случае после установки AspNetCore.2.0.6.RuntimePackageStore_x64.exeи DotNetCore.2.0.6-WindowsHosting.exeмне нужно перезапустить сервер, чтобы он работал без ошибки 502 плохого шлюза и прокси.

ОБНОВИТЬ:

Есть способ использовать его без перезагрузки: https://stackoverflow.com/a/50808634/3634867

John_J
источник
2

Откройте командную строку с учетными данными администратора

Введите следующую команду и нажмите Enter

> IISRESET

ИЛИ

Откройте Visual Studio 2017 с учетными данными администратора

Введите следующую команду в консоли диспетчера пакетов и нажмите Enter.

PM > IISRESET

PM> IISRESET
Attempting stop...
Internet services successfully stopped
Attempting start...
Internet services successfully restarted
Акшай Мишра
источник
2

Для меня это было вызвано установкой разных версий .Net Core. Я сопоставил свой сервер разработки и производственный сервер, и он сработал.

Carla
источник
1

У меня тоже была эта проблема (ошибка возникла как на VS 15, так и на 17). Однако на VS15 он вернул CONNECTION_REFUSEDошибку, а на VS17 - вернул ASP.NET Core 1.0 on IIS error 502.5.

FIX

  1. Перейдите в каталог вашего проекта и найдите скрытую папку .vs(она находится в папке проектов dir). (Не забудьте показать скрытые файлы / папки)

  2. Закрыть VS

  3. Удалить .vs-папку
  4. Запустите VS от имени администратора (VS-папка будет воссоздана VS)
Unicco
источник
1

Вот что я понял, и это произошло недавно в Windows 10 после установки обновления. Насколько я понял, было установлено обновление Защитника Windows, предполагающее, что мой "Project.dll" (основной проект asp.net) ведет себя как вирус, поэтому он был удален.

Итак, одна из первых вещей, которые я предлагаю вам сделать, прежде чем вы начнете устанавливать / удалять файлы, - это проверить, чтобы убедиться, что ваш "Project.dll" находится там, где он должен быть.

Скопируйте его обратно в то место, если его там больше нет.

Если у вас возникли проблемы с копированием файла обратно, добавьте исключение в папку проекта в защитнике Windows . ( Узнайте, как это сделать, здесь .)

Это сработало для меня мгновенно, и я повторил это на нескольких серверах приложений.

Сеун С. Лаваль
источник
1

Для меня это было то, что connectionString в Startup.cs было нулевым в:

services.AddDbContext<ApplicationDbContext>(options => options.UseSqlServer(Configuration.GetConnectionString("DefaultConnection")));

и он был пустым, потому что приложение не просматривало appsettings.json в поисках строки подключения.

Пришлось изменить Program.cs на:

public static void Main(string[] args)
{
    BuildWebHost(args).Run();
}

public static IWebHost BuildWebHost(string[] args) =>
     WebHost.CreateDefaultBuilder(args)
     .ConfigureAppConfiguration((context, builder) => builder.SetBasePath(context.HostingEnvironment.ContentRootPath)
     .AddJsonFile("appsettings.json").Build())
     .UseStartup<Startup>().Build();
Андрей Добрин
источник
1

Я понятия не имею, почему это сработало для меня, но я использую проверку подлинности Windows, и у меня был этот фрагмент кода на моем BuildWebHostвходе Program.cs:

.UseStartup<Startup>()
.UseHttpSys(options =>
{
    options.Authentication.Schemes =
        AuthenticationSchemes.NTLM | AuthenticationSchemes.Negotiate;
    options.Authentication.AllowAnonymous = false;
})
.Build();

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

BuildWebHost теперь похоже

public static IWebHost BuildWebHost(string[] args) =>
    WebHost.CreateDefaultBuilder(args)
    .UseStartup<Startup>()
    .Build();
Bassie
источник
У меня есть проверка подлинности файлов cookie в ядре aspnet. Как мне настроить?
kudlatiger
@kudlatiger К сожалению , я не уверен , - Ваш лучший выбор , чтобы создать отдельный вопрос
Bassie
1

Я получал ту же ошибку и обнаружил, что проблема заключалась в том, что во время публикации в Azure мой файл web.config был изменен, поэтому следующая строка выглядела так:

<aspNetCore processPath="bin\IISSupport\VSIISExeLauncher.exe" arguments="-argFile IISExeLauncherArgs.txt" forwardWindowsAuthToken="false" stdoutLogEnabled="false" startupTimeLimit="3600" requestTimeout="23:00:00" />

Проблема для производства заключается в содержании аргументов: "-argFile IISExeLauncherArgs.txt"

Похоже, что эта проблема будет решена в следующем .NET Core SDK (в настоящее время находится в предварительной версии), но на данный момент временным решением будет добавить этот блок в файл .csproj:

<Target Name="bug_242_workaround" AfterTargets="_TransformWebConfig">
    <Exec Command="powershell &quot;(Get-Content '$(PublishDir)Web.config').replace(' -argFile IISExeLauncherArgs.txt', '') | Set-Content '$(PublishDir)Web.config'&quot;" />
  </Target>

Это изменит файл web.config и удалит проблемную часть для публикации.

Ссылка: https://github.com/aspnet/websdk/issues/242

Надеюсь, поможет.

Родриго Пирес
источник
Добавляемые атрибуты startupTimeLimit и requestTimeout кажутся ошибкой инструментария .
Mark G
1

У меня сработало после изменения конфигурации публикации.

введите описание изображения здесь

MAFAIZ
источник
Извините, я не вижу изображений в своей организации. Загрузка изображений заблокирована (в большинстве организаций).
Auguste
0

У меня была аналогичная проблема (Asp.Net Core 2.x), которая была вызвана попыткой запустить 32-разрядное приложение asp.net core в IIS на 64-разрядном сервере Windows. Основная причина заключалась в том, что автоматически сгенерированный файл web.config (если ваш проект не включает его явно, чего нет в основных проектах asp.net по умолчанию) не содержит полного пути к исполняемому файлу dotnet. Когда вы устанавливаете пакет хостинга на 64-битный компьютер, он устанавливает 64-битную и 32-битную версии dotnet, но путь по умолчанию разрешается на 64-битный, и ваше 32-битное основное приложение asp.net не загружается. В вашем браузере вы можете увидеть ошибку 502.5, и если вы посмотрите журнал событий сервера, вы можете увидеть код ошибки 0x80004005. Если вы попытаетесь запустить dotnet.exe из командной строки, чтобы загрузить dll основного приложения asp.net на этот сервер, вы можете увидеть ошибку типа «BadImageFormatException» или «

<?xml version="1.0" encoding="utf-8"?>
<configuration>
    <location path="." inheritInChildApplications="false">
        <system.webServer>
            <handlers>
                <add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModule" resourceType="Unspecified" />
            </handlers>
            <aspNetCore processPath="C:\Program Files (x86)\dotnet\dotnet.exe" arguments=".\My32BitAspNetCoreApp.dll" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" />
       </system.webServer>
   </location>
</configuration>
Натан
источник
0

У меня та же проблема, и причина в моем случае заключалась в том, что ядро ​​EF пыталось прочитать строку подключения из appsettings.development.jsonфайла. Я открыл его и обнаружил, что строка подключения была прокомментирована.

//{
//  "ConnectionStrings": {
//    "DefaultConnection": "Server=vaio;Database=Goldentaurus;Trusted_Connection=True;",
//    "IdentityConnection": "Server=vaio;Database=GTIdentity;Trusted_Connection=True;"
//  }
//}

Затем я отменил их, как показано ниже, и проблема решена:

{
  "ConnectionStrings": {
    "DefaultConnection": "Server=vaio;Database=Goldentaurus;Trusted_Connection=True;",
    "IdentityConnection": "Server=vaio;Database=GTIdentity;Trusted_Connection=True;"
  }
}
yogihosting
источник