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: \ програмні файли \ dotnet \ dotnet.exe" "C: \ fullpath \ PROJECT.dll"

в командному рядку, який дав мені набагато більш значущу помилку:

"Не було знайдено вказаного фреймворку" Microsoft.NETCore.App ", версія" 1.0.1 ". - Перевірте залежність програми та націліть на рамкову версію, встановлену на: Встановлено наступні версії: 1.0.0 - Крім того, встановіть рамкову версію '1.0.1'.

Як бачите, у мене на сервері була встановлена ​​неправильна версія NET Core. Мені вдалося запустити свою програму після видалення попередньої версії 1.0.0 та встановлення правильної версії 1.0.1.

У мене була така ж проблема, в моєму випадку це був недостатній дозвіл ідентифікації користувача мого пулу прикладних програм на публікації на IIS сторінці asp.net doc, для цієї помилки вказано пару причин:

• Якщо ви опублікували автономні програми, переконайтеся , що ви не встановили платформу 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\існує в налаштуваннях системної PATH.
• Для портативного додатка dotnet.exeможе бути недоступним для ідентифікації користувача пулу програм. Переконайтеся, що ідентифікатор користувача AppPool має доступ до C:\Program Files\dotnetкаталогу.
• Переконайтесь, що ви правильно посилалися на проміжне програмне забезпечення інтеграції IIS, викликавши .UseIISIntegration()метод програми WebHostBuilder().
• Якщо ви використовуєте .UseUrls()метод розширення під час самостійного хостингу з Kestrel, переконайтесь, що він розміщений перед .UseIISIntegration()ввімкненим методом розширення WebHostBuilder(). .UseIISIntegration()повинен встановити значення Urlдля зворотного проксі-сервера під час запуску Kestrel позаду IIS і не мати його значення, яке буде перевищено .UseUrls().

У моєму випадку це було четвертою причиною, я змінив його, клацнувши правою кнопкою миші пул додатків, і в розширених налаштуваннях у розділі Process Model я встановив особу користувачеві з достатньою дозволом:

У мене це було з жорстким скиданням IIS (я тільки що встановив хостинг-пакет).

Виявляється, що просто натиснути "Перезапустити" в IIS Manager недостатньо. Мені просто довелося відкрити командний рядок і набрати '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 походить від Universal C Runtime, що входить до перерозподілюваного 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
    }
  }
}

Змініть версію з "версії": "1.1.2" на "версія": "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 помилка зникла.

Була однакова проблема, і всі рішення не спрацювали. Знайшов цей дорогоцінний камінь і подумав, що я пройду, якщо він допоможе комусь іншому. Встановіть на сервер 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" />

Тепер, будь ласка, спробуйте змінити вищевказану конфігурацію у візуальному студійному рішенні на<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>

У мене було те саме питання. Я змінив ідентифікацію пулу додатків на обліковий запис мережі. Тоді я чітко встановив шлях до donet.exe в web.config, щоб програма працювала належним чином, як @danielyewright сказав у своєму коментарі до github . Він працює після встановлення шляху.

Дякую

Поділившись, що в моєму випадку ця помилка була через те, що я забув оновити project.json за допомогою:

"buildOptions": {
    "emitEntryPoint": true
  }

У мене була та сама помилка, про яку йшлося, з тими ж проблемами, які описані VSG24 у Пропонованій відповіді - неприємне повідомлення про помилку під час введення «dotnet» у CMD:

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

Я вирішив це, вручну встановивши наступні два оновлення на 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.

Виправлення

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

2. Закрити VS

3. Видалити .vs-папку
4. Запустіть VS як адміністратор (папка .vs буде відтворена VS)

Ось що я зрозумів, і це сталося нещодавно в Windows 10 після встановлення оновлення. З того, що я зібрав, було встановлено оновлення Windows Defender, яке припускало, що мій "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/isissue/242

Сподіваюся, це допомагає.

Працював для мене після зміни конфігурації публікації.

У мене була аналогічна проблема (Asp.Net Core 2.x), яка була викликана спробою запустити 32-розрядний основний додаток asp.net в IIS на 64-бітному сервері Windows. Першопричиною було те, що web -config, який автоматично генерується (якщо ваш проект явно не включає жодного, який основні проекти asp.net за замовчуванням не мають), не містить повного шляху до виконуваної точки дотнету. Коли ви встановите пакет хостингу на 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;"
  }
}