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

Ответ 1

Итак, у меня появился новый сервер, на этот раз это 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 С++ Redistributable для Visual Studio 2015.

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

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

Ответ 2

Я смог исправить это, выполнив

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

Ответ 3

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

• Если вы опубликовали автономное приложение, подтвердите, что вы не установили платформу в buildOptions of project.json, которая конфликтует с RID публикации. Например, не указывайте платформу 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\ существует в настройках System PATH.
• Для портативного приложения dotnet.exe может быть недоступно для идентификации пользователя пула приложений. Убедитесь, что идентификатор пользователя AppPool имеет доступ к каталогу C:\Program Files\dotnet.
• Подтвердите, что вы правильно ссылались на промежуточное программное обеспечение интеграции IIS, вызывая метод .UseIISIntegration() для приложений WebHostBuilder().
• Если вы используете метод расширения .UseUrls() при самообслуживании с помощью Kestrel, убедитесь, что он расположен до метода расширения .UseIISIntegration() на WebHostBuilder(). .UseIISIntegration() должен установить Url для обратного прокси при запуске Kestrel за IIS и не переопределить его значение с помощью .UseUrls().

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

Ответ 4

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

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

Ответ 5

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

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

Измените версию с "версии": "1.1.2" на "версия": "1.1.1" и все нормально работает

Ответ 6

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

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

Ответ 7

Если бы одна и та же проблема и все решения не работали. Нашел этот камень и подумал, что пройду, если это поможет кому-то другому. Установите на сервере 2012 R2 ошибку DLL, попробуйте переустановить VS С++ 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 С++ 2015.

Ответ 8

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

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

Ответ 9

SOLVED Я просто столкнулся с тем же вопросом сегодня, когда вы развертываетесь до 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"/> выше конфигурацию в решении 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"/>

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

Ответ 10

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

Ответ 11

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

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

Ответ 12

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

Спасибо

Ответ 13

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

"buildOptions": {
    "emitEntryPoint": true
  }

Ответ 14

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

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

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

• KB2919355
• KB2999226

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

Ответ 15

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

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

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

Ответ 16

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

Ответ 17

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

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

Ответ 18

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

ОБНОВИТЬ:

Существует способ, которым вы можете использовать его без перезагрузки: fooobar.com/questions/6651325/...

Ответ 19

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

Ответ 20

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

Ответ 21

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

Ответ 22

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

FIX

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

• Закрыть VS

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

Ответ 23

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

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

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

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

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

Ответ 24

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

Ответ 25

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

Ответ 26

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

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

Проблема для Production - это содержимое аргументов: "-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

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

Ответ 27

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

Ответ 28

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

<?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>

Ответ 29

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

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

> IISRESET

ИЛИ ЖЕ

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

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

PM> IISRESET

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

Ответ 30

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