studio - ¿Cómo obtener los detalles de error de una aplicación ASP.NET 5 desplegada en los sitios web de Azure?

publish web app azure

Question

Tengo una solución ASP.NET 5 con un sitio web y varias bibliotecas de proyectos. Estoy usando MVC 6 y Entity Framework 7. Localmente, la aplicación funciona bien y hasta hoy funcionaba también en Azure implementada como un sitio web de Azure.

Pero hoy, después de la última implementación en Azure, recibí un error de 500 como este en la puesta en marcha (todavía funciona bien localmente):

Traté de obtener más detalles al:

• usando diagnósticos de middleware
• agregar la configuración customError / httpError en el archivo web.config
• descargando la página DetailedError generada

Parece que el error / excepción se está produciendo durante el paso de Inicio / Configuración, pero sigo recibiendo la página de error genérica sin detalles. Incluso la versión generada en el servidor (carpeta DetailedErrors) Obtuve esto:

He habilitado el seguimiento de solicitudes fallidas pero todavía no hay información útil:

Incluso si elimino el código en el Inicio / Configurar y agrego un try / catch como se sugiere, recibí el mismo error sin détails. Parece ser un problema de configuración / compilación pero difícil de depurar sin información.

Answer 1

¿Has registrado el archivo eventlog.xml? Está en el directorio D: / home / LogFiles. Puede verlo desde el sitio Kudu de su aplicación o usar la extensión Visor de eventos de Azure Websites.

Answer 2

Crea un web.config dentro de tu carpeta wwwroot con este contenido:

<configuration>
<system.web>
<customErrors mode="Off" />
</system.web>
</configuration>

Answer 3

¿Intentó usar la depuración remota de Azure Webapp? Lo más probable es que ocurra alguna excepción que sea responsable de esto y si mira su ventana DEBUG OUTPUT, puede ver qué excepción está sucediendo y luego cambiar la configuración de Visual Studio para romper esa excepción y ver dónde está sucediendo. revise este artículo para comprender cómo depurar remotamente - http://blogs.msdn.com/b/webdev/archive/2013/11/05/remote-debugging-a-window-azure-web-site-with-visual- studio-2013.aspx

Answer 4

Tuve el mismo problema y pasé mucho tiempo intentando profundizar en los registros de errores, etc. (todas las demás soluciones indicadas anteriormente). Ninguno de ellos da ninguna pista de lo que salió mal.

Lo que hice que me ayudó finalmente a ver el error fue simplemente intentar publicar en un IIS local (después de que la aplicación web azul ejecute su dnx en IIS internamente).

De inmediato, pude ver que hay un error cuando IIS intenta compilar el origen. (en mi caso era un paquete nuget malformado).

En resumen:

Recrear lo que sucede en la aplicación web azul publicando en IIS local.

Answer 5

Debe establecer la propiedad de configuración de la aplicación ASPNET_DETAILED_ERRORS en verdadero en el archivo web.config .

Ejemplo de mi archivo editado web.config:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
<appSettings>
<add key="bootstrapper-version" value="1.0.0-beta6" />
<add key="runtime-path" value="../approot/runtimes" />
<add key="dnx-version" value="1.0.0-beta6" />
<add key="dnx-clr" value="clr" />
<add key="dnx-app-base" value="../approot/src/MyApp" />
<!-- This will turn on detailed errors when deployed to remote servers -->
<!-- This setting is not recommended for production -->
<add key="ASPNET_DETAILED_ERRORS" value="true" />
</appSettings>
<system.web>
<httpRuntime targetFramework="4.5.1" />
</system.web>
</configuration>

Answer 6

En mi caso con beta5, los errores personalizados en web.config no ayudaron, el IIS local estaba bien y al agregar un manejador de excepciones no se mostró nada. Lo único que funcionó fue atacar con armas nucleares y redesplegar.

Answer 7

En RC1 (a partir de beta8, tal vez), uno debería usar aparentemente:

app.UseDeveloperExceptionPage();

.. que aparentemente solo funciona si app.Properties["host.AppMode"] es "development" .

Pero esto no funcionó para mí. El mensaje de error que recibí fue específicamente "Se produjo un error al iniciar la aplicación" . He descubierto que ninguna de las configuraciones dadas lo resolverá porque el error se está produciendo antes de que se ejecuten las configuraciones.

De alguna manera, la carpeta de destino de publicación debe haberse corrompido durante la publicación porque descubrí que la eliminación del directorio de implementación completo y la reedición resolvió el problema .

De lo contrario, aquí está la referencia: http://docs.asp.net/en/latest/fundamentals/diagnostics.html

Answer 8

He experimentado exactamente el mismo error con una aplicación web que ejecuta dnx-clr-win-x64.1.0.0-rc1-update1. Hice la implementación directamente desde Visual Studio 2015 Enterprise Update 1. Descubrí que el sitio funcionaba cada vez que hacía la primera implementación en una aplicación web recién creada. Comenzando con la segunda implementación (incluso cuando implementé exactamente el mismo contenido), comencé a ver el Internal Server Error 500. Eso me llevó a la siguiente solución:

La habilitación de "Eliminar archivos adicionales en el destino" en el asistente de publicación de Visual Studio me lo arregló.

Answer 9

En la configuración de la aplicación de la aplicación web, en la sección Configuración de la aplicación, agregue (o cambie el valor) Hosting: Environment to Development . Luego obtienes la misma página de error que en tu desarrollo local. En mi Startup.cs, tengo el método regular Configure () con el siguiente código: (todavía en MVC 1.0 RC1-final)

 if (env.IsDevelopment())
{
app.UseBrowserLink();
app.UseDeveloperExceptionPage();
app.UseDatabaseErrorPage();
}
else

¡Espero que esto ayude!

Answer 10

Los errores que ocurren en el inicio en una aplicación ASPNET5 son realmente difíciles de rastrear cuando se ejecuta la aplicación en Azure (al menos con beta 3). Con suerte, encuentran una manera de mejorar la experiencia. Tuve que recurrir a desmantelar mi startup hasta los huesos y luego agregar código línea por línea hasta que ocurrió la falla (en mi caso, era una variable de entorno faltante).

También utilicé un código como este (solo para la depuración) que podría ayudar según el lugar donde ocurra el error:

public void Configure(IApplicationBuilder app, IHostingEnvironment env )
{
try
{
// Add MVC to the request pipeline.
app.UseMvc(routes =>
{
routes.MapRoute(
name: "default",
template: "{controller}/{action}/{id?}"
);
});
}
//exceptions in startup are really bad when running in azure, all you will get is an internal server error
//this code will write the exception message to the browser instead. Only use for debugging!!!
catch (Exception ex)
{
app.Run(async context =>
{
context.Response.ContentType = "text/plain";
await context.Response.WriteAsync(ex.Message);
});
}
}

Actualización 27/10/2016 Mucho ha cambiado desde mi respuesta original. La última guía se publica aquí:

https://docs.asp.net/en/latest/fundamentals/hosting.html

Entonces, agrega:

.CaptureStartupErrors (true) y .UseSetting (WebHostDefaults.DetailedErrorsKey, "true") en su WebHostBuilder de esta manera:

 var host = new WebHostBuilder()
.CaptureStartupErrors(true)
.UseSetting(WebHostDefaults.DetailedErrorsKey, "true")
.UseKestrel()
.UseContentRoot(Directory.GetCurrentDirectory())
.UseIISIntegration()
.UseStartup<Startup>()
.Build();