ASP.NET Core 1.0 en IIS error 502.5

Acabo de actualizar mi servidor (Windows 2012R2) al .Net Core 1.0 RTMpaquete de alojamiento de Windows del anterior .Net Core 1.0 RC2. Mi aplicación funciona en mi PC sin ningún problema, pero el servidor sigue mostrando:

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

Anteriormente trabajó con la versión RC2. No sé qué podría salir mal.

Esto es todo lo que el visor de eventos dice:

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

¡la peor parte es que los registros de aplicaciones están vacíos! Me refiero a que esos archivos stdout_xxxxxxxxx.log están completamente vacíos y todos tienen un tamaño de 0 bytes.

¿¿Qué tengo que hacer?? ¿Cómo puedo saber la causa del error si no está registrado?

Pude arreglarlo ejecutando

"C: \ Archivos de programa \ dotnet \ dotnet.exe" "C: \ fullpath \ PROJECT.dll"

en el símbolo del sistema, lo que me dio un error mucho más significativo:

"No se encontró el marco especificado 'Microsoft.NETCore.App', versión '1.0.1'. - Verifique las dependencias de la aplicación y elija una versión del marco instalada en: C: \ Archivos de programa \ dotnet \ shared \ Microsoft.NETCore.App - Se instalan las siguientes versiones: 1.0.0 - Alternativamente, instale la versión del marco '1.0.1'.

Como puede ver, tenía instalada la versión de NET Core incorrecta en mi servidor. Pude ejecutar mi aplicación después de desinstalar la versión anterior 1.0.0 e instalar la versión correcta 1.0.1.

Tuve el mismo problema, en mi caso fue un permiso insuficiente de la identidad de usuario de mi grupo de aplicaciones, en la publicación en la página IIS de asp.net doc, hay un par de razones para este error:

• Si ha publicado una aplicación autónoma, confirman que no ha configurado una plataforma de buildOptionsde project.jsonque los conflictos con el RID publicación. Por ejemplo, no especifique una plataforma de x86 y publique con un RID de win81-x64 ( dotnet publish -c Release -r win81-x64). El proyecto se publicará sin advertencias ni errores, pero fallará con las excepciones registradas anteriormente en el servidor.
• Verifique el processPathatributo en el <aspNetCore>elemento en web.config para confirmar que es dotnetpara una aplicación portátil o. \ My_application.exe para una aplicación autónoma.
• Para una aplicación portátil, es dotnet.exeposible que no se pueda acceder a través de la configuración de PATH. Confirme que C:\Program Files\dotnet\existe en la configuración de PATH del sistema.
• Para una aplicación portátil, es dotnet.exeposible que no sea accesible para la identidad de usuario del grupo de aplicaciones. Confirme que la identidad del usuario de AppPool tenga acceso al C:\Program Files\dotnetdirectorio.
• Confirme que ha hecho referencia correctamente al middleware de integración de IIS llamando al .UseIISIntegration()método de la aplicación WebHostBuilder().
• Si está utilizando el .UseUrls() método de extensión cuando se autohospeda con Kestrel, confirme que esté colocado antes del .UseIISIntegration()método de extensión en WebHostBuilder(). .UseIISIntegration()debe establecer el Urlpara el proxy inverso al ejecutar Kestrel detrás de IIS y no tener su valor anulado por .UseUrls().

En mi caso, fue la cuarta razón, la cambié haciendo clic con el botón derecho en mi grupo de aplicaciones, y en la configuración avanzada en Modelo de proceso, configuré la Identidad para un usuario con suficiente permiso:

Conseguí que esto funcionara con un restablecimiento completo de IIS (acababa de instalar el paquete de alojamiento).

Resulta que simplemente presionar 'Reiniciar' en el Administrador de IIS no es suficiente. Solo tenía que abrir un símbolo del sistema y escribir 'iisreset'

Así que obtuve un nuevo servidor, esta vez es Windows 2008R2 y mi aplicación funciona bien.

No puedo decir con certeza cuál fue el problema con el servidor anterior, pero tengo una idea.

Entonces, debido a que previamente compilé la aplicación sin ninguna plataforma en mente, me dio la dllversión que solo funciona si el host de destino tiene el .Net Core Windows Hostingpaquete instalado. En mi caso estaba instalado y estuvo bien .

Después de que la aplicación no funcionó, decidí compilarla como una aplicación de consola con win7-x64tiempo de ejecución. Esta vez, en el momento en que ejecuté el exede mi aplicación en el servidor, se bloqueó con un error sobre una dll faltante:

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

Ese dll es de Universal C Runtime que se incluye en Visual C ++ Redistributable para Visual Studio 2015 .

Intenté instalar ese paquete (tanto x64 como x86) pero falló cada vez (no sé por qué) en Windows Server 2012 R2.

Pero cuando intenté instalarlos en el nuevo servidor, Windows Server 2008 R2, se instalaron correctamente. Esa podría haber sido la razón detrás de esto, pero aún no puedo decirlo con certeza.

Tuve el mismo problema al publicar la aplicación web. Si alguien aún tiene este problema, lo solucionó cambiando {AppName} .runtimeconfig.json

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

Cambie la versión de "versión": "1.1.2" a "versión": "1.1.1" y todo funcionó bien

Yo tuve el mismo problema.

Para averiguar la fuente exacta, encendí el registro en el archivo web.config:

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

y creó la subcarpeta de registros en la carpeta raíz MyWebService.

Después de reiniciar IIS e intentar ejecutar la API, recibí un error y faltaba el Core Runtime adecuado. Después de descargar una instalación DotNetCore.1.0.5_1.1.2-WindowsHosting, el error desapareció.

Tuve el mismo problema y todas las soluciones no funcionaron. Encontré esta joya y pensé en pasarla si ayuda a alguien más. Instale en Server 2012 R2 y obtenga el error de DLL que falta, intente reinstalar VS C ++ 2015 y obtenga un error. La solución es hacer lo siguiente:

Parece que el archivo C:\ProgramData\Package Cache\...\packages\Patch\x64\Windows8.1-KB2999226-x64.msutiene problemas para instalarse. Abra el símbolo del sistema de administración:

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

NOTA: reemplace "..." con el nombre de carpeta correcto. Después de esto, reinstale el paquete VS C ++ 2015.

Tuve un problema similar, y para citar a Sherlock Holmes: " cuando has eliminado lo imposible, lo que queda, por improbable que sea, ¿debe ser la verdad? "

Verifiqué si el marco .NET al que me dirigía estaba instalado en el servidor y resultó que no lo estaba. Instalé 4.6.2 .NET Framework y funcionó.

Tuve este problema en mi servidor de producción después de que mi proyecto VS se actualizara automáticamente a .NET Core 1.1.2.

Simplemente instalé el tiempo de ejecución del núcleo 1.1.2 .net desde aquí en mi servidor de producción: https://www.microsoft.com/net/download/core#/runtime

SOLUCIONADO Acabo de resolver el mismo problema hoy mientras implementaba en AZURE . Luego intenté lo mismo para IIS local, obtuve el mismo problema. Como soy nuevo en .net CORE, luché unas horas antes de resolverlo.

En nuestra solución, después de publicar en IIS, observé mi archivo web.confile, especialmente debajo de la línea <aspNetCore processPath="bin\IISSupport\VSIISExeLauncher.exe" arguments="-argFile IISExeLauncherArgs.txt" forwardWindowsAuthToken="false" stdoutLogEnabled="false" />

En nuestra carpeta de implementación, el web.config generado se ve así:<aspNetCore processPath="dotnet" arguments=".\Yodlee.dll -argFile IISExeLauncherArgs.txt" forwardWindowsAuthToken="false" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" />

Ahora POR FAVOR intente cambiar la configuración anterior en la solución de Visual Studio a<aspNetCore processPath="bin\IISSupport\VSIISExeLauncher.exe" forwardWindowsAuthToken="false" stdoutLogEnabled="false" />

En nuestra nueva carpeta de implementación, el archivo web.config generado se ve así:<aspNetCore processPath="dotnet" arguments=".\Yodlee.dll" forwardWindowsAuthToken="false" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" />

Y esto RESUELTO mi problema, espero que ayude.

Tuve el mismo problema cuando actualicé mi máquina de desarrollo a Core 1.0.1, pero olvidé actualizar el servidor.

Recibí el error HTTP 502.5 mientras intentaba publicar mi API .NET Core 2.0 en AWS EB, y lo resolví agregando el siguiente código al .csproj:

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

Tuve el mismo problema. Cambié la identidad del grupo de aplicaciones a la cuenta de servicio de red. Luego establecí explícitamente la ruta a dotnet.exe en web.config para que la aplicación funcione correctamente como dijo @danielyewright en su github comentario de . Funciona después de establecer el camino.

Gracias

Compartiendo que en mi caso, este error se debió a que olvidé actualizar project.json con:

"buildOptions": {
    "emitEntryPoint": true
  }

Tuve el mismo error en cuestión, con los mismos problemas descritos por VSG24 en Respuesta propuesta: mensaje de error desagradable al escribir 'dotnet' en CMD:

El programa no puede iniciarse porque falta api-ms-win-crt-runtime-l1-1-0.dll

Resolví esto instalando manualmente las siguientes 2 actualizaciones en Windows Server 2012 R2 (y los requisitos previos y todas las demás actualizaciones vinculadas; lea atentamente las instrucciones de instalación en el sitio web de Microsoft):

1. KB2919355
2. KB2999226

Espero que esto ayude a alguien.

Enfrenté el mismo problema cuando intenté publicar la versión de depuración de mi aplicación web. Este conjunto de archivos no contenía el archivo web.configcon el valor adecuado de atributo processPath.

Tomé este archivo de la versión de lanzamiento, se asignó un valor a la ruta a mi archivo exe.

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

En mi caso, hubo un problema con la versión Net Core instalada en el servidor. Acabo de instalar la misma versión que en mi máquina de desarrollo y todo está bien :-)

Necesitaba instalar la última versión de .net Core que se encuentra aquí . No es necesario reiniciar el sitio o el servidor

Lo resolví agregando "permiso de edición" a la aplicación del sitio, lo asigné al directorio físico y luego seleccioné el usuario de Windows que podría tener acceso a esta carpeta raíz. (red privada).

En mi caso, después de instalar AspNetCore.2.0.6.RuntimePackageStore_x64.exey DotNetCore.2.0.6-WindowsHosting.exe, necesito reiniciar el servidor para que funcione sin 502 puerta de enlace incorrecta y error de proxy.

ACTUALIZAR:

Hay una manera de usarlo sin reiniciar: https://stackoverflow.com/a/50808634/3634867

Abra el símbolo del sistema con credenciales de administrador

Escriba el siguiente comando y presione enter

> IISRESET

O

Abra Visual Studio 2017 con credenciales de administrador

Escriba el siguiente comando en la Consola del Administrador de paquetes y presione enter

PM > IISRESET

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

Para mí, fue causado por tener diferentes versiones de .Net Core instaladas. Coincidí con mi servidor de desarrollo y producción y funcionó.

También tuve este problema (el error se produjo tanto en VS 15 como en 17). Sin embargo, en VS15 devolvió un CONNECTION_REFUSEDerror y en VS17 volvió ASP.NET Core 1.0 on IIS error 502.5.

REPARAR

1. Navegue al directorio de su proyecto y ubique la carpeta oculta .vs(se encuentra en el directorio de la carpeta de proyectos). (Recuerde mostrar archivos / carpetas ocultos)

2. Cerrar VS

3. Eliminar carpeta .vs
4. Inicie VS como administrador (la carpeta .vs será recreada por VS)

Esto es lo que pensé, y esto sucedió recientemente en Windows 10 después de que se instaló una actualización. Por lo que reuní, se instaló una actualización de Windows Defender que asumía que mi "Project.dll" (un proyecto principal de asp.net) se comportaba como un virus, por lo que se eliminó.

Entonces, una de las primeras cosas que le sugiero que haga antes de comenzar a instalar / desinstalar cosas es verificar para confirmar que su "Project.dll" está donde debería estar.

Cópielo de nuevo en la ubicación si ya no está allí.

Si tiene dificultades para volver a copiar el archivo, agregue una exclusión a la carpeta de su proyecto en Windows Defender . ( Aprenda cómo hacer eso aquí ).

Esto funcionó para mí instantáneamente y lo repetí en múltiples servidores de aplicaciones.

Para mí fue que connectionString en Startup.cs era nulo en:

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

y fue nulo porque la aplicación no estaba buscando en appsettings.json la cadena de conexión.

Tuve que cambiar Program.cs a:

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();

No tengo idea de por qué esto funcionó para mí, pero estoy usando la autenticación de Windows y tenía este código en mi BuildWebHosten Program.cs:

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

Después de eliminar el .UserHttpSysbit, ahora funciona y todavía puedo autenticarme como usuario de dominio.

BuildWebHost ahora parece

public static IWebHost BuildWebHost(string[] args) =>
    WebHost.CreateDefaultBuilder(args)
    .UseStartup<Startup>()
    .Build();

Recibí el mismo error y descubrí que el problema era que durante la publicación en Azure, mi archivo web.config se modificó, por lo que la siguiente línea terminó así:

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

El problema para Producción son los contenidos de los argumentos: "-argFile IISExeLauncherArgs.txt"

Parece que este problema se abordará en el próximo SDK de .NET Core (actualmente en versión preliminar), pero por ahora, la solución es agregar este bloque al archivo .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>

Esto modificará web.config y eliminará la parte problemática para su publicación.

Referencia: https://github.com/aspnet/websdk/issues/242

Espero eso ayude.

Me funcionó después de cambiar la configuración de publicación.

Tuve un problema similar (Asp.Net Core 2.x) que fue causado al intentar ejecutar una aplicación principal asp.net de 32 bits en IIS en un servidor de Windows de 64 bits. La causa principal fue que el web.config que se genera automáticamente (si su proyecto no incluye explícitamente uno, que los proyectos principales de asp.net no lo hacen de forma predeterminada) no contiene la ruta completa al ejecutable dotnet. Cuando instale el paquete de alojamiento en una máquina de 64 bits, se instalarán las versiones de 64 y 32 bits de dotnet, pero la ruta se resolverá de forma predeterminada en 64 bits y su aplicación principal asp.net de 32 bits no se cargará. En su navegador puede ver un error 502.5 y si mira el registro de eventos del servidor puede ver el código de error 0x80004005. Si intenta ejecutar dotnet.exe desde un símbolo del sistema para cargar la dll de la aplicación principal de asp.net en ese servidor, es posible que vea un error como "BadImageFormatException" o "

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

Tuve el mismo problema y la razón en mi caso fue que el núcleo de EF estaba tratando de leer la cadena de conexión del appsettings.development.jsonarchivo. Lo abrí y encontré que la cadena de conexión estaba comentada.

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

Luego los eliminé como a continuación y el problema se resolvió:

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