c# - publicar - ASP.NET Core 1.0 en el error 502.5 de IIS
publicar asp.net core iis (30)
Abrir 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 Package Manager Console y presione enter
PM > IISRESET
PM> IISRESET
Attempting stop...
Internet services successfully stopped
Attempting start...
Internet services successfully restarted
Acabo de actualizar mi servidor (Windows 2012R2) al paquete de alojamiento de Windows
.Net Core 1.0 RTM
del
.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 funcionaba con la versión RC2. No sé qué podría salir mal.
Todo esto es espectador de eventos dice:
Failed to start process with the commandline ''dotnet ./MyWebApp.dll''. Error code = ''0x80004005''.
¡Lo peor es que los registros de aplicaciones están vacíos! Quiero decir 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 cuando no está registrado?
Así que obtuve un nuevo servidor, esta vez es Windows 2008R2 y mi aplicación funciona bien.
No puedo decir con certeza cuál era el problema con el servidor anterior, pero tengo una idea.
Entonces, debido a que anteriormente compilé la aplicación
sin
ninguna plataforma en mente, me dio la versión
dll
que solo funciona si el host de destino tiene instalado el paquete de
.Net Core Windows Hosting
.
En mi caso fue
instalado y eso estuvo bien
.
Después de que la aplicación no funcionó, decidí compilarla como una aplicación de consola con
win7-x64
como tiempo de ejecución.
Esta vez, en el momento en que ejecuté el
exe
de mi aplicación en el servidor, se bloqueó con un error sobre un dll faltante:
The program can''t start because api-ms-win-crt-runtime-l1-1-0.dll is missing
Esa dll es de Universal C Runtime que se incluye en Visual C ++ Redistributable para Visual Studio 2015 .
Traté de instalar ese paquete (x64 y 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.
Compartiendo que en mi caso este error fue porque olvidé actualizar project.json con:
<aspNetCore processPath="./My.Web.App.exe" ... />
En mi caso fue un problema con la versión de Net Core instalada en el servidor. Acabo de instalar la misma versión que en mi máquina de desarrollo y todo está bien :-)
En mi caso, después de instalar
AspNetCore.2.0.6.RuntimePackageStore_x64.exe
y
DotNetCore.2.0.6-WindowsHosting.exe
, necesito
reiniciar el servidor
para que
DotNetCore.2.0.6-WindowsHosting.exe
sin 502 mal gateway y error de proxy.
ACTUALIZAR:
Hay una manera de usarlo sin reiniciar: https://.com/a/50808634/3634867
Estaba recibiendo el error HTTP 502.5 al intentar publicar mi API .NET Core 2.0 en AWS EB, y lo resolví agregando el siguiente código al .csproj:
"buildOptions": {
"emitEntryPoint": true
}
Esto es lo que pensé, y esto sucedió recientemente en Windows 10 después de que se instaló una actualización. De lo que reuní, se instaló una actualización de Windows Defender que asumió que mi "Project.dll" (un proyecto básico de asp.net) se comportó como un virus, por lo que se eliminó.
Por lo tanto, una de las primeras cosas que le sugiero que haga antes de comenzar a instalar / desinstalar cosas es verificar que su "Project.dll" esté donde debería estar.
Copie de nuevo a la ubicación si ya no está allí.
Si tiene dificultades para copiar el archivo, agregue una exclusión a su carpeta de proyecto en Windows Defender . ( Aprenda cómo hacer eso aquí ).
Esto funcionó para mí al instante, y lo repetí en varios servidores de aplicaciones.
Lo resolví agregando "permiso de edición" a la aplicación del sitio, asignado al directorio físico y luego seleccioné el usuario de Windows que podría tener acceso a esta carpeta raíz. (red privada).
Me enfrenté al 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.config
con el valor adecuado del atributo
processPath
.
Tomé este archivo de la versión de lanzamiento, el valor se asignó a la ruta a mi archivo exe.
<PropertyGroup>
<PublishWithAspNetCoreTargetManifest>false</PublishWithAspNetCoreTargetManifest>
</PropertyGroup>
Necesitaba instalar la última versión de .net Core que se encuentra here . No es necesario reiniciar el sitio o el servidor
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
BuildWebHost
en
Program.cs
:
.UseStartup<Startup>()
.UseHttpSys(options =>
{
options.Authentication.Schemes =
AuthenticationSchemes.NTLM | AuthenticationSchemes.Negotiate;
options.Authentication.AllowAnonymous = false;
})
.Build();
Después de eliminar el bit
.UserHttpSys
, ahora funciona y todavía puedo autenticarme como usuario de dominio.
BuildWebHost
ahora se parece a
public static IWebHost BuildWebHost(string[] args) =>
WebHost.CreateDefaultBuilder(args)
.UseStartup<Startup>()
.Build();
Obtuve esto trabajando con un restablecimiento completo de IIS (acababa de instalar el paquete de alojamiento).
Resulta que simplemente presionando ''Reiniciar'' en el Administrador de IIS no es suficiente. Solo tenía que abrir un símbolo del sistema y escribir ''iisreset''
Para mí fue causado por tener diferentes versiones de .Net Core instaladas. Emparejé mi servidor de desarrollo y producción y funcionó.
Para mí fue que connectionString en Startup.cs era nulo en:
services.AddDbContext<ApplicationDbContext>(options => options.UseSqlServer(Configuration.GetConnectionString("DefaultConnection")));
y era 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();
Pude arreglarlo ejecutando
"C: / Archivos de programa / dotnet / dotnet.exe" "C: / fullpath / PROJECT.dll"
en el símbolo del sistema, 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 apunte a una versión de 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 de marco ''1.0.1''.
Como puede ver, tenía la versión incorrecta de NET Core instalada 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.
Recibí 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 1.1.2 .net core runtime desde aquí en mi servidor de producción: https://www.microsoft.com/net/download/core#/runtime
Recibía 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 esta línea siguiente 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 la producción son los contenidos de los argumentos: "-argFile IISExeLauncherArgs.txt"
Parece que este problema se solucionará en el próximo SDK de .NET Core (actualmente en vista previa), pero por ahora, la solución consiste en agregar este bloque al archivo .csproj:
<Target Name="bug_242_workaround" AfterTargets="_TransformWebConfig">
<Exec Command="powershell "(Get-Content ''$(PublishDir)Web.config'').replace('' -argFile IISExeLauncherArgs.txt'', '''') | Set-Content ''$(PublishDir)Web.config''"" />
</Target>
Esto modificará web.config y eliminará la parte problemática para la publicación.
Referencia: https://github.com/aspnet/websdk/issues/242
Espero eso ayude.
También tuve este problema (el error ocurrió tanto en VS 15 como en 17).
Sin embargo, en VS15 devolvió un error
CONNECTION_REFUSED
y en VS17 devolvió
ASP.NET Core 1.0 on IIS error 502.5
.
REPARAR
-
Navegue a su directorio de proyectos y ubique la carpeta oculta
.vs
(se encuentra en el directorio de la carpeta de proyectos). (Recuerde mostrar archivos / carpetas ocultos) -
Cerrar VS
- Eliminar carpeta .vs
- Inicie VS como administrador (la carpeta .vs será recreada por VS)
Tuve el mismo error en cuestión, con los mismos problemas descritos por VSG24 en la 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 cuidadosamente las instrucciones de instalación en el sitio web de Microsoft):
- KB2919355
- KB2999226
Espero que esto ayude a alguien.
Tuve el mismo problema Cambié la identidad del grupo de aplicaciones a la cuenta de servicio de red. Luego configuré explícitamente la ruta a dotnet.exe en web.config para que la aplicación funcione correctamente como @danielyewright dijo en su comentario de github . Funciona después de establecer el camino.
Gracias
Tuve el mismo problema al publicar la aplicación web. Si alguien todavía tiene este problema solucionado, cambie {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
Tuve el mismo problema cuando actualicé mi máquina de desarrollo a Core 1.0.1, pero olvidé actualizar el servidor.
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 archivo
appsettings.development.json
.
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 confirmé 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;"
}
}
Tuve el mismo problema y todas las soluciones no funcionaron. Encontré esta gema y pensé en pasarla si ayuda a alguien más. Instale en el Servidor 2012 R2 obteniendo el error de falta de DLL, 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.msu
tiene problemas para instalarse.
Abrir símbolo del sistema admin hacer:
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 correcto de la carpeta. Después de esto, reinstale el paquete VS C ++ 2015.
Tuve el mismo problema, en mi caso fue un permiso insuficiente de la identidad del usuario de mi grupo de aplicaciones, al publicar en la página IIS de asp.net doc, hay un par de razones enumeradas para este error:
-
Si publicó una aplicación autónoma, confirme que no configuró una plataforma en
buildOptions
deproject.json
que entra en conflicto con el RID de 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 advertencia o error, pero fallará con las excepciones registradas anteriormente en el servidor. -
Verifique el atributo
processPath
en el elemento<aspNetCore>
en web.config para confirmar que esdotnet
para una aplicación portátil o. / My_application.exe para una aplicación autónoma. -
Para una aplicación portátil,
dotnet.exe
podría no ser accesible a través de la configuración de RUTA. Confirme queC:/Program Files/dotnet/
exista en la configuración de RUTA del sistema. -
Para una aplicación portátil,
dotnet.exe
podría no ser accesible para la identidad del usuario del grupo de aplicaciones. Confirme que la identidad de usuario de AppPool tiene acceso al directorioC:/Program Files/dotnet
. -
Confirme que ha hecho referencia correctamente al middleware de integración IIS llamando al método
.UseIISIntegration()
del.UseIISIntegration()
de la aplicación. -
Si está utilizando el método de extensión
.UseUrls()
cuando se.UseUrls()
con Kestrel, confirme que esté ubicado antes del método de extensiónWebHostBuilder()
enWebHostBuilder()
..UseIISIntegration()
debe establecer laUrl
para el proxy inverso cuando se ejecuta Kestrel detrás de IIS y no tener su valor anulado por.UseUrls()
.
En mi caso, fue la cuarta razón, lo cambié haciendo clic derecho en mi grupo de aplicaciones, y en la configuración avanzada en Modelo de proceso, configuré la identidad a un usuario con suficiente permiso:
Tuve un problema similar (Asp.Net Core 2.x) causado por intentar ejecutar una aplicación asp.net core de 32 bits en IIS en un servidor de Windows de 64 bits. La causa raíz 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 incluyen por defecto) no contiene la ruta completa al ejecutable de dotnet. Cuando instala el paquete de alojamiento en una máquina de 64 bits, instalará las versiones de 64 y 32 bits de dotnet, pero la ruta se resolverá de manera predeterminada a 64 bits y su aplicación núcleo 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 su dll de la aplicación asp.net core en ese servidor, puede ver un error como "BadImageFormatException" o "se intentó cargar un programa con un formato incorrecto". La solución que funcionó para mí fue agregar un web.config a mi proyecto (y despliegue) y en ese web.config establecer la ruta completa a la versión de 32 bits de 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>
Tuve un problema similar, y para citar a Sherlock Holmes: " cuando hayas 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 resulta que no lo estaba. Instalé 4.6.2 .NET Framework y funcionó.
Yo tuve el mismo problema.
Para averiguar el origen exacto, activé el inicio de sesión en el archivo web.config:
<aspNetCore processPath="dotnet" arguments="./MyWebService.dll" stdoutLogEnabled="**true**" stdoutLogFile="./logs/stdout" />
y creó una 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ó.
SOLUCIONADO Acabo de pasar por el mismo problema hoy mientras lo implementaba en AZURE . Luego intenté lo mismo para IIS local, obtuve el mismo problema. Como soy nuevo en .net CORE, luché unas pocas 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 archivo 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 web.config generado se ve así:
<aspNetCore processPath="dotnet" arguments="./Yodlee.dll" forwardWindowsAuthToken="false" stdoutLogEnabled="false" stdoutLogFile="./logs/stdout" />
Y esto resolvió mi problema, espero que ayude.