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

Я только что обновил свой сервер (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 байт.

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

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

"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.

У меня была такая же проблема, в моем случае это было недостаточное разрешение удостоверения пользователя моего пула приложений при публикации на странице 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().

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

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

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

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

У меня была такая же проблема при публикации веб-приложения. Если у кого-то все еще есть эта проблема, исправьте ее, изменив {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», и все работает нормально.

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

Чтобы узнать его точный источник, я включил логин в файл 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 ошибка исчезла.

Была такая же проблема, и все решения не сработали. Нашел этот драгоценный камень и подумал, что пройду мимо, если он кому-то поможет. Установите на 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.

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

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

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

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

РЕШЕНО. Я столкнулся с той же проблемой сегодня при развертывании в 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" />

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

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

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

  <PropertyGroup>
    <PublishWithAspNetCoreTargetManifest>false</PublishWithAspNetCoreTargetManifest>
  </PropertyGroup>

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

Спасибо

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

"buildOptions": {
    "emitEntryPoint": true
  }

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

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

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

1. KB2919355
2. KB2999226

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

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

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

<aspNetCore processPath=".\My.Web.App.exe" ... />

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

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

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

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

ОБНОВИТЬ:

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

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

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

> IISRESET

ИЛИ

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

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

PM > IISRESET

PM> IISRESET
Attempting stop...
Internet services successfully stopped
Attempting start...
Internet services successfully restarted

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

У меня тоже была эта проблема (ошибка возникла как на 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)

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

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

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

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

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

Для меня это было то, что 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();

Я понятия не имею, почему это сработало для меня, но я использую проверку подлинности 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();

Я получал ту же ошибку и обнаружил, что проблема заключалась в том, что во время публикации в 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

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

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

У меня была аналогичная проблема (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>

У меня та же проблема, и причина в моем случае заключалась в том, что ядро ​​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;"
  }
}