Ошибка HTTP 502.5 — сбой запуска вне процесса ANCM после обновления до ASP.NET Core 2.2

Мое решение:

• удалить все проекты с каталогом
• создавать новые проекты
• скопируйте все файлы, кроме program.cs и startup.cs
• ручное копирование из классов запуска и программы в новый startup.cs и новый program.cs

Работает.

Я столкнулся с этой проблемой и нашел другое решение. Для меня это было то, что у меня был пакет, который устарел с приложением (я обновил его на NuGet, и библиотека не была заменена в производстве). Обновление пакета исправило это для меня.

Обратите внимание: мне пришлось вручную запустить dotnet.exe с dll проекта, чтобы увидеть сообщение, которое исправило это для меня.

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

В моем случае я обновил некоторые пакеты nuget до net core 2.2, но у меня не было установленного net core 2.2 sdk, поэтому я пошел на веб-сайт net core, чтобы загрузить последнюю версию sdk или пакет времени выполнения, а затем я сделал net stop was /y, а затем a net start w3svc в CMD от имени администратора. Проблема решена для меня.

Я столкнулся с этой ошибкой после попытки публикации с VS2017 на рабочий сервер Windows 2016. (Он отлично работал в IIS Express на моем локальном ПК с Win10.)

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

В разделе «Публикация» > «Настроить» > «Настройки» (левая вкладка) мне пришлось установить целевую среду выполнения с «Portable» на «win-x64» (или что-то другое, что имеет отношение к вашей среде). Я также выбрал «Удалить дополнительные файлы в месте назначения».

«Портативный» — это настройка по умолчанию. Я не уверен, что нужно для правильной работы "Portable" среды выполнения, но может сэкономить кому-то еще время, если "Portable" среда выполнения вам не нужна.

Вообще говоря, я получаю эту ошибку, если что-то не соответствует моей среде. Например, однажды я обновлял один из своих проектов до .Net Core 3.1 с версии 2.2 и не устанавливал на своем сервере пакет ASP.NET Core Runtime Hosting Bundle:

https://dotnet.microsoft.com/download/dotnet-core/3.1

Кроме того, вы можете получить эту ошибку, если для вашего пула приложений установлено значение «Истина» для «Включить 32-разрядные приложения». Пытаться:

IIS Manager > Application Pools > app pool name > (right click) Advanced Settings > Enable 32-Bit Applications = False

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

dotnet publish -c release -r win7-x64 --output:bin/self_contained

Мое исправление состояло в том, чтобы вместо этого опубликовать «зависимое от платформы» развертывание с помощью следующей команды:

dotnet publish --output:bin/framework_dependent

На сервере разработки было установлено несколько версий .NET Core (2.2.3 и 2.2.5) в этой папке *C:\Program Files\dotnet\shared

Я до сих пор не понимаю, почему автономная публикация не работает. Вы можете подумать, что автономная публикация будет более надежным методом, но в моем случае это не так.

Этот Запись в блоге .NET Core был полезен.

Я столкнулся с этой проблемой сегодня на своем хостинге - локально все в порядке, но как только я публикую, я получаю эту ошибку.

Я просмотрел пакеты и обнаружил, что некоторые основные элементы .net были обновлены до предварительной версии 3.0.

Затем я изменил параметр сборки в VS2019 с «Зависимый от платформы» на «Автономный». Сборка и публикация заняли в 5 раз больше времени, но теперь это работает.

Сейчас я выясняю у техподдержки хоста, в чем может быть проблема - официально они поддерживают только 2.1/2.2, так что это могут быть пакеты из Preview 3.0, однако целевой сборкой является 2.2.

В моем случае это был неправильно установленный уровень журнала в файле appsettings.json. Вместо Предупреждение у меня был Предупреждать, и это привело к сбою приложения с указанной выше ошибкой.

Я получил ту же ошибку при развертывании основного приложения .Net, нацеленного на .Net framework на сервере Windows. Я проверил средство просмотра событий на сервере и оказалось, что на сервере не установлен .net 4.7.2.

Его установка решила проблему для меня.

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

Еще один сценарий, который вызвал эту проблему для меня:

Я запускаю идентификатор пула приложений с учетной записью службы, и мне пришлось запустить dotnet dev-certs https под этим пользователем, чтобы избавиться от «System.InvalidOperationException: невозможно настроить конечную точку HTTPS». во время запуска.

Если сброс проекта и ручное копирование классов Program и Startup у вас сработало, значит, что-то явно напутано. С этим связаны более серьезные основные проблемы. Использование модели хостинга OutOfProcess допустимо, но с .Net Core 2.2 вы сможете использовать модель хостинга InProcess, поскольку она, естественно, быстрее: все обрабатывается в IIS без дополнительного HTTP-перехода между IIS и сервером Kestrel вашего приложения. .

Если вы щелкнете правой кнопкой мыши файл проекта в обозревателе решений Visual Studio, убедитесь, что тег AspNetCoreModuleName имеет значение AspNetCoreModuleV2 (в отличие от более старого AspNetCoreModule). Кроме того, просмотрите журнал событий приложений Windows, чтобы определить потенциального виновника. Несмотря на то, что сообщения об ошибках несколько загадочны, они могут указывать на точный номер строки в коде, вызвавшей сбой.

Наконец, если вы используете CI/CD с TFS, в файле appsettings.json могут быть переменные среды, которые не были должным образом заменены фактическими значениями (URL-адресами и т. д.).

Такой же сбой произошел при публикации проекта. Проблема связана с последним пакетом Microsoft.AspNetCore.App. Просто понизьте его с 2.2.x до 2.2.0 или перейдите на dotnet.microsoft.com/download/dotnet-core/2.2 и получите последнюю версию установщика dotnet-хостинг.

Похоже, у меня была такая же проблема. Это происходит потому, что если у вас нет файла global.json в решении, то VS создаст (опубликует) основное приложение .net с последней версией, установленной на вашем компьютере. Итак, я делаю следующее решение:

добавьте файл global.json с основной версией .net.

{
   "sdk": {
      "version": "2.2.402"
   }
}

Из docs.microsoft.com:

global.json can be placed anywhere in the file hierarchy. The CLI searches upward from the project directory for the first global.json it finds. You control which projects a given global.json applies to by its place in the file system. The .NET CLI searches for a global.json file iteratively navigating the path upward from the current working directory. The first global.json file found specifies the version used. If that version is installed, that version is used. If the SDK specified in the global.json is not found, the .NET CLI rolls forward to the latest SDK installed. Roll-forward is the same as the default behavior, when no global.json file is found.

https://docs.microsoft.com/en-us/dotnet/core/versions/selection

Будьте осторожны с публикацией.

Когда я публикую его в своей среде PreProd, эта конфигурация работает хорошо: Портативный

Но в моей среде Prod эта конфигурация не работает. Мне пришлось выбрать конкретный: Win-x64

Я не знаю причину этого. Если кто-то знает, я буду благодарен знать!

Проблема возникает, когда я пытаюсь развернуть веб-сайт asp.net core (внепроцессная модель хостинга) на Windows Server 2012r2 IIS в производственной среде. Я исправил это с помощью этого решения:

Изменить идентификатор пула приложений на администратора.

Это случилось со мной, когда я развернул код, используя Ядро Entity Framework с миграции, и возникло несоответствие между состоянием базы данных и миграциями в коде.

Для меня проблема была вызвана dotnet publish созданием записи web.config stdoutLogFile = ".\logs\stdout". Правильное значение должно быть stdoutLogFile = "\\?\%home%\LogFiles\stdout".

Ссылка MSDN: https://blogs.msdn.microsoft.com/waws/2018/06/10/устранение неполадок-http-502-5-startup-issues-in-azure-appservice-for-asp-net-core-websites/

Это может быть ошибка в среде выполнения ASP.NET Core 2.2.0, которая могла быть исправлена ​​в более поздней версии.

Я также получил ту же проблему. И когда я посмотрел на окно вывода моего решения.

Затем я смог увидеть другую ошибку «Целевой процесс завершился, не вызвав событие запуска CoreCLR.», чтобы исправить это, мне пришлось удалить Microsoft.AspNetCore.All из моих пакетов Nuget и установить Microsoft.AspNetCore.App. У меня тоже был установите правильный .Net SDK из здесь. Как только это будет сделано, перезагрузите мою машину и откройте решение, ошибка исчезла. Надеюсь, поможет

у вас есть 2 решения (этот ответ работает на сервере Windows, я ничего не знаю о сервере Linux).

первый:

• скопируйте всю папку (кроме папки bin и obj) вашего проекта на сервер

• откройте cmd в папке вашего проекта, затем выполните эту команду: dotnet run тогда вам будут показаны все предупреждения и ошибки (если у вас есть ошибка в приведенной выше команде, вы не распознаете загрузку dot net core sdk из эта ссылка)

второй:

• вы должны изменить атрибут hostingModel с OutOfProcess на inprocess в web.config, и вы можете изменить stdoutLogEnabled на true значение для получения ошибки вашего проекта в папке журналов
• прочитайте ошибки ваших проектов и исправьте их.

в моем случае web.config:

<?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 = "dotnet" arguments = ".\BMS.dll" stdoutLogEnabled = "false" stdoutLogFile = ".\logs\stdout" hostingModel = "OutOfProcess" />
    </system.webServer>
  </location>
</configuration>

и я меняю его на:

<?xml version = "1.0" encoding = "utf-8"?>
<configuration>
  <location path = "." inheritInChildApplications = "false">
    <system.webServer>
      <handlers>
        <add name = "aspNetCore" path = "*" verb = "*" modules = "AspNetCoreModuleV2" resourceType = "Unspecified" />
      </handlers>
      <aspNetCore processPath = "dotnet" arguments = ".\BMS.dll" stdoutLogEnabled = "true" stdoutLogFile = ".\logs\stdout" hostingModel = "inprocess" />
    </system.webServer>
  </location>
</configuration>

Это случилось со мной, когда я впервые опубликовал веб-приложение Azure. Вот как я это решил:

Просмотрите сайт с помощью Kudo/FTP. В корневой папке есть папка LogFiles, где вы найдете eventlog.xml. В этом файле я мог видеть, что в моем веб-приложении было SqlException, когда Entity Framework Core пытался настроить базу данных, что заставило меня проверить разрешения базы данных (что было проблемой для меня).

Если вы работаете с ASP.Net Core версии 2.2, то в appsettings.json просто прокомментируйте строку -

"Разрешенные хосты": "*"

это решает проблему. Мое приложение работает нормально.

Эта ошибка может произойти из-за многих причин. В моем случае это было исключением из-за недопустимого формата appsettings.json. Как я узнал, включив журнал stdout в web.config.

Вот что сработало для меня: - Я запустил файл запуска проекта в развернутой (IIS) папке. Обратите внимание: это не решит проблему, но проинформирует вас о том, в чем проблема. В моем случае причиной проблемы была неудачная миграция базы данных.

Кажется, у каждого есть свой ответ на этот вопрос. У меня тоже была эта проблема. Как вы можете сказать, есть много разных вещей, которые вызывают эту проблему. Если вы не найдете какое-либо из этих решений полезным или у вас возникнут проблемы при использовании всех этих различных решений, вы можете попробовать запустить свое приложение из командной строки из папки публикации.

После публикации, если вы получите эту ошибку, перейдите в папку публикации, а затем откройте окно команды/терминала, после этого введите dotnet .\YourStartupProject.dll, вы должны получить ошибку исключения, которая должна упростить решение проблемы.

Например, это ошибка, которую я получил при попытке использовать новую среду без настройки SQL-сервера, и, конечно же, я получил эту ошибку.

Application startup exception: System.Exception: Could not resolve a service of type 
'YourStartupProject.DataServices.DbContext.DbContext' for the parameter 
'context' of method 'Configure' on type 'YourStartupProject.Startup'. ---> 
System.ArgumentNullException: Value cannot be null.
Parameter name: connectionString

Как только вы устраните свою ошибку, попробуйте еще раз, промойте, повторите.

Для меня проблема заключалась в отсутствующем файле appsettings.json.

Я выбираю соответствующий файл appsettings.json (appsettings.production.json или appsettings.development.json) на основе переменной среды. Оказывается, appsettings.json требуется, даже если вы его не используете.

Моя проблема была с файлом web.config после публикации. В processPath в теге aspNetCore отсутствовало расширение файла. В моем случае это был .exe

В моем случае EF Migrations выдало исключение о блокировке выполнения одного из них из-за потенциальной потери данных. Мне пришлось заглянуть в пользовательские журналы приложений (чаще всего в папку «Журнал»), чтобы узнать это.

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

В общем, когда мы получаем такую ​​ошибку, мы должны сосредоточиться на вещах, которые влияют на логику запуска приложения.

Для меня это был файл web.config, убедитесь, что он у вас есть и правильно указали пути

<aspNetCore processPath = "%LAUNCHER_PATH%" arguments = "%LAUNCHER_ARGS%" stdoutLogEnabled = "false" stdoutLogFile = ".\bin\Debug\netcoreapp2.0\logs\stdout">

Также средство просмотра событий может быть полезно для обнаружения ошибок при запуске приложения.

Выполните следующие действия:

• создайте каталог в корне вашего проекта: logs/stdout

• откройте файл web.config из корня вашего проекта и найдите эту строку:

  <aspNetCore processPath = ".\web.exe" stdoutLogEnabled = "false" stdoutLogFile = ".\logs\stdout" />
  

• установите stdoutLogEnabled как true и сохраните его

• перезагрузите приложение и посмотрите журналы в каталоге: logs/stdout

Эта проблема также возникает, когда требуемое значение, такое как конечная точка API, которое требуется во время запуска проекта, отсутствует в параметре приложения json. Возможно, вы параметризуете его и не указываете значение для параметра. Я получаю это в Azure DevOps

Я установил stdoutLogEnabled на true в Web.config. Итак, в журнале я обнаружил, что ошибка была BadImageFormatException. На самом деле мое веб-приложение было скомпилировано в 32-битном режиме, поэтому мне пришлось указать 32-битную версию dotnet в Web.config:

<aspNetCore processPath = "C:\Program Files (x86)\dotnet\dotnet" arguments = ".\MyApp.dll" stdoutLogEnabled = "true" stdoutLogFile = ".\logs\stdout" hostingModel = "OutOfProcess" />

Еще один ответ, который может помочь другим людям в том же случае: у нас есть AppService в Azure, где 3 проекта NETCore развернуты по 3 разным путям:

• Один для Интернета (/webapi)
• Один для мобильных устройств (/mobileapi)
• Один для бессерверных функций, в нашем случае это были AzureFunctions (/functionapi).

После обновления до NETCore3.x мы поняли, что модель хостинга по умолчанию была «В процессе», поэтому нам пришлось отредактировать файл .csproj, чтобы явно установить модель хостинга «Вне процесса» следующим образом:

  <PropertyGroup>
    <TargetFramework>netcoreapp3.1</TargetFramework>
    <AspNetCoreHostingModel>OutOfProcess</AspNetCoreHostingModel>
  </PropertyGroup>

Но этого оказалось недостаточно: ведь нам еще и нужно редактировать Program.cs. Почему ? Потому что в Program.cs, сгенерированном по умолчанию в NETCore3.x, у вас есть следующий код:

    public static IHostBuilder CreateHostBuilder(string[] args)
    {
        return Host.CreateDefaultBuilder(args)
            .ConfigureWebHostDefaults(webBuilder =>
            {
                webBuilder.UseStartup<Startup>();
                webBuilder.ConfigureKestrel(o => o.AddServerHeader = false);
            });
    }

Когда мы заменили этот старый код версией NETCore2.x, как показано ниже:

    public static IWebHostBuilder CreateWebHostBuilder(string[] args)
    {
        return WebHost.CreateDefaultBuilder(args)
            .UseKestrel(options => options.AddServerHeader = false)
            .UseStartup<Startup>();
    }

После развертывания ошибка 502.5 Ошибка запуска ANCM исчезла :) Надеюсь, этот ответ поможет другим людям.

Кстати, я знаю, что этот пост связан с NETCore2.2, мы также столкнулись с той же проблемой, но решили переключиться на NETCore3.1, потому что NETCore2.2 больше не поддерживается, и эта версия также содержала ошибки в некоторых других моментах.

Мой сайт .NET Core работал нормально, но через некоторое время я получил эту ошибку (Ошибка HTTP 502.5 — Ошибка запуска вне процесса ANCM...); Я пробовал разные методы. В итоге я Добавить новый веб-сайт в IIS (с другим портом), после чего ошибка решилась.

Я выполнил шаг ниже и решил. Удачи:)

Шаг – 1. Перейдите в обозреватель решений <Щелкните правой кнопкой мыши <Свойство

Шаг 2:

Покажите свою платформу .Net Core или измените ее в соответствии с вашими требованиями, но убедитесь, что все остальные существующие библиотеки DLL поддерживаются или нуждаются в обновлении.

Шаг 3: Загрузите пакет .NetCore на свой ПК
См. ссылку ниже https://dotnet.microsoft.com/download

Даже я столкнулся с проблемой, когда публиковал dotnet core 2.1 до 3.1 и .netstandard 1.1 до 2.1 с dotnet core 3.1 sdk.

Когда использовалась команда dotnet publish -c Release, файлы находились в bin\Release\netcoreapp3.1, ранее это была bin\Release\netcoreapp2.1\publish папка.

Не уверен в точных настройках, но у нас есть папка публикации, но развертывание из родительского каталога папки публикации помогло.

У меня возникла эта проблема в проекте ASP.NET Core 2.2, и она была решена для меня только проектами Чистый и Восстановить.

Для меня проблема заключалась в создании базы данных из фреймворка сущностей, поэтому я перехожу к своему SQL-серверу, безопасности, логинам и добавляю новый логин для моего пула приложений IIS и даю новому логину свои серверные роли.