Soluciones problemas en ASP.NET Core en Azure App Service e IIS

Enviado 04/09/2019 por Fabian

Este artículo proporciona información sobre errores comunes de inicio de aplicaciones e instrucciones sobre cómo diagnosticar errores cuando una aplicación se implementa en Azure App Service o IIS:

Errores de inicio de la aplicación
Explica escenarios comunes de código de estado HTTP de inicio.

Solucionar problemas en el Servicio de aplicaciones de Azure
Proporciona consejos de solución de problemas para las aplicaciones implementadas en el Servicio de aplicaciones de Azure.

Solucionar problemas en IIS
Proporciona consejos de solución de problemas para aplicaciones implementadas en IIS o que se ejecutan en IIS Express localmente. La guía se aplica a las implementaciones de escritorio de Windows Server y Windows.

Borrar cachés de paquetes
Explica qué hacer cuando los paquetes incoherentes rompen una aplicación al realizar actualizaciones importantes o cambiar versiones de paquetes.

Recursos adicionales
Enumera temas adicionales de solución de problemas.

Errores de inicio de la aplicación

En Visual Studio, un proyecto de ASP.NET Core está predeterminado en el alojamiento IIS Express durante la depuración. 502.5 - Falla de proceso o 500.30 - Falla de inicio que ocurre cuando la depuración local se puede diagnosticar utilizando los consejos de este tema.

403.14 Prohibido

La aplicación no se inicia. Se registra el siguiente error:

The Web server is configured to not list the contents of this directory.

El error generalmente es causado por una implementación defectuosa en el sistema de alojamiento, que incluye cualquiera de los siguientes escenarios:

  • La aplicación se implementa en la carpeta incorrecta en el sistema de alojamiento.
  • El proceso de implementación no pudo mover todos los archivos y carpetas de la aplicación a la carpeta de implementación en el sistema de alojamiento.
  • El web.config archivo no se encuentra en el despliegue, o las web.config contenido del archivo es incorrecto.

Realice los siguientes pasos:

  1. Elimine todos los archivos y carpetas de la carpeta de implementación en el sistema de alojamiento.
  2. Vuelva a implementar el contenido de la carpeta de publicación de la aplicación en el sistema de alojamiento utilizando su método normal de implementación, como Visual Studio, PowerShell o implementación manual:
    • Confirme que el archivo web.config está presente en la implementación y que su contenido es correcto.
    • Cuando aloje en Azure App Service, confirme que la aplicación se implemente en la D:\home\site\wwwrootcarpeta.
    • Cuando la aplicación esté alojada por IIS, confirme que la aplicación esté implementada en la ruta física de IIS que semuestra en la Configuración básica del Administrador de IIS .
  3. Confirme que todos los archivos y carpetas de la aplicación se implementan comparando la implementación en el sistema de alojamiento con el contenido de la carpeta de publicación del proyecto .

Para obtener más información sobre el diseño de una aplicación ASP.NET Core publicada, consulte la estructura de directorios de ASP.NET Core . Para obtener más información sobre el archivo web.config , consulte ASP.NET Core Module .

Error interno de servidor 500

La aplicación se inicia, pero un error impide que el servidor complete la solicitud.

Este error ocurre dentro del código de la aplicación durante el inicio o al crear una respuesta. La respuesta puede no contener contenido o puede aparecer como un error interno del servidor 500 en el navegador. El registro de eventos de la aplicación generalmente indica que la aplicación se inició normalmente. Desde la perspectiva del servidor, eso es correcto. La aplicación se inició, pero no puede generar una respuesta válida. Ejecute la aplicación en un símbolo del sistema en el servidor o habilite el registro estándar de ASP.NET Core Module para solucionar el problema.

500.0 Falla de carga del manipulador en proceso

El proceso de trabajo falla. La aplicación no se inicia.

El módulo ASP.NET Core no puede encontrar .NET Core CLR y no encuentra el controlador de solicitud en proceso ( aspnetcorev2_inprocess.dll ). Mira esto:

500.0 Fallo de carga del manipulador fuera de proceso

El proceso de trabajo falla. La aplicación no se inicia.

El módulo principal ASP.NET no puede encontrar el controlador de solicitudes de alojamiento fuera de proceso. Asegúrese de que aspnetcorev2_outofprocess.dll esté presente en una subcarpeta junto a aspnetcorev2.dll .

502.5 Falla del proceso

El proceso de trabajo falla. La aplicación no se inicia.

El Módulo principal de ASP.NET intenta iniciar el proceso de trabajo pero no puede iniciarse. La causa de una falla de inicio del proceso generalmente se puede determinar a partir de las entradas en el registro de eventos de la aplicación y el registro estándar de ASP.NET Core Module.

Una condición de falla común es que la aplicación está mal configurada debido a que apunta a una versión del marco compartido ASP.NET Core que no está presente. Compruebe qué versiones del marco compartido de ASP.NET Core están instaladas en la máquina de destino. El marco compartido es el conjunto de ensamblajes ( archivos .dll ) que están instalados en la máquina y a los que hace referencia un metapaquete como Microsoft.AspNetCore.AppLa referencia de metapaquete puede especificar una versión mínima requerida. Para obtener más información, consulte El marco compartido .

La página de error 502.5 Error de proceso se devuelve cuando un alojamiento o una configuración incorrecta de la aplicación hace que el proceso de trabajo falle:

Error al iniciar la aplicación (Código de error '0x800700c1')

EventID: 1010
Source: IIS AspNetCore Module V2
Failed to start application '/LM/W3SVC/6/ROOT/', ErrorCode '0x800700c1'.

La aplicación no pudo iniciarse porque no se pudo cargar el ensamblado de la aplicación ( .dll ).

Este error ocurre cuando hay una falta de coincidencia de bits entre la aplicación publicada y el proceso w3wp / iisexpress.

Confirme que la configuración de 32 bits del grupo de aplicaciones es correcta:

  1. Seleccione el grupo de aplicaciones en los Grupos de aplicaciones del Administrador de IIS .
  2. Seleccione Configuración avanzada en Editar grupo de aplicaciones en el panel Acciones .
  3. Establezca Habilitar aplicaciones de 32 bits :
    • Si implementa una aplicación de 32 bits (x86), establezca el valor en True.
    • Si implementa una aplicación de 64 bits (x64), establezca el valor en False.

Confirme que no hay un conflicto entre una propiedad de MSBuild en el archivo del proyecto y el bitness publicado de la aplicación.

Reajuste de conexion

Si se produce un error después de enviar los encabezados, es demasiado tarde para que el servidor envíe un error interno del servidor 500 cuando se produce un error. Esto sucede a menudo cuando ocurre un error durante la serialización de objetos complejos para una respuesta. Este tipo de error aparece como un error de restablecimiento de conexión en el cliente. El registro de aplicaciones puede ayudar a solucionar este tipo de errores.

Límites de inicio predeterminados

El módulo principal de ASP.NET está configurado con un valor predeterminado de startupTimeLimit de 120 segundos. Cuando se deja en el valor predeterminado, una aplicación puede tardar hasta dos minutos en iniciarse antes de que el módulo registre una falla del proceso. Para obtener información sobre la configuración del módulo, consulte Atributos del elemento aspNetCore .

Solucionar problemas en Azure App Service

 Importante

Versiones de vista previa de ASP.NET Core con Azure App Service

Las versiones preliminares de ASP.NET Core no se implementan en Azure App Service de manera predeterminada. Para hospedar una aplicación que usa una versión de vista previa de ASP.NET Core, vea Implementar la versión de vista previa de ASP.NET Core en Azure App Service .

Registro de eventos de la aplicación (Azure App Service)

Para acceder al Registro de eventos de la aplicación, use la hoja Diagnosticar y resolver problemas en Azure Portal:

  1. En Azure Portal, abra la aplicación en App Services .
  2. Seleccione Diagnosticar y resolver problemas .
  3. Seleccione el encabezado Herramientas de diagnóstico .
  4. En Herramientas de soporte , seleccione el botón Eventos de la aplicación .
  5. Examine el último error proporcionado por la entrada IIS AspNetCoreModule o IIS AspNetCoreModule V2 en la columna Fuente .

Una alternativa al uso de la hoja Diagnosticar y resolver problemas es examinar el archivo de registro de eventos de la aplicación directamente usando Kudu :

  1. Abra Herramientas avanzadas en el área Herramientas de desarrollo . Seleccione el botón Ir → . La consola de Kudu se abre en una nueva pestaña o ventana del navegador.
  2. Usando la barra de navegación en la parte superior de la página, abra la consola de depuración y seleccione CMD .
  3. Abra la carpeta LogFiles .
  4. Seleccione el ícono de lápiz junto al archivo eventlog.xml .
  5. Examina el registro. Desplácese hasta la parte inferior del registro para ver los eventos más recientes.

Ejecute la aplicación en la consola Kudu

Muchos errores de inicio no producen información útil en el registro de eventos de la aplicación. Puede ejecutar la aplicación en la Consola de ejecución remota de Kudu para descubrir el error:

  1. Abra Herramientas avanzadas en el área Herramientas de desarrollo . Seleccione el botón Ir → . La consola de Kudu se abre en una nueva pestaña o ventana del navegador.
  2. Usando la barra de navegación en la parte superior de la página, abra la consola de depuración y seleccione CMD .

Probar una aplicación de 32 bits (x86)

Lanzamiento actual

  1. cd d:\home\site\wwwroot
  2. Ejecuta la aplicación:

La salida de la consola de la aplicación, que muestra cualquier error, se canaliza a la consola Kudu.

Implementación dependiente del marco que se ejecuta en una versión preliminar

Requiere la instalación de la extensión del sitio ASP.NET Core {VERSION} (x86) Runtime.

  1. cd D:\home\SiteExtensions\AspNetCoreRuntime.{X.Y}.x32{X.Y}es la versión en tiempo de ejecución)
  2. Ejecuta la aplicación: dotnet \home\site\wwwroot\{ASSEMBLY NAME}.dll

La salida de la consola de la aplicación, que muestra cualquier error, se canaliza a la consola Kudu.

Probar una aplicación de 64 bits (x64)

Lanzamiento actual

La salida de la consola de la aplicación, que muestra cualquier error, se canaliza a la consola Kudu.

Implementación dependiente del marco que se ejecuta en una versión preliminar

Requiere la instalación de la extensión del sitio ASP.NET Core {VERSION} (x64) Runtime.

  1. cd D:\home\SiteExtensions\AspNetCoreRuntime.{X.Y}.x64{X.Y}es la versión en tiempo de ejecución)
  2. Ejecuta la aplicación: dotnet \home\site\wwwroot\{ASSEMBLY NAME}.dll

La salida de la consola de la aplicación, que muestra cualquier error, se canaliza a la consola Kudu.

Registro estándar stdout de ASP.NET Core Module (Servicio de aplicaciones de Azure)

El registro estándar de ASP.NET Core Module a menudo registra mensajes de error útiles que no se encuentran en el registro de eventos de la aplicación. Para habilitar y ver registros estándar:

  1. Vaya a la hoja Diagnosticar y resolver problemas en Azure Portal.
  2. En SELECCIONAR CATEGORÍA DE PROBLEMAS , seleccione el botón Abajo de la aplicación web .
  3. En Soluciones sugeridas > Habilitar redirección de registro de Stdout , seleccione el botón para abrir Kudu Console para editar Web.Config .
  4. En la Consola de diagnóstico de Kudu , abra las carpetas en el sitio de ruta wwwroot . Desplácese hacia abajo para mostrar el archivo web.config al final de la lista.
  5. Haga clic en el ícono de lápiz junto al archivo web.config .
  6. Conjunto stdoutLogEnabled a truey cambiar el stdoutLogFile ruta a: \\?\%home%\LogFiles\stdout.
  7. Seleccione Guardar para guardar el archivo web.config actualizado .
  8. Haz una solicitud a la aplicación.
  9. Regrese al portal de Azure. Seleccione la hoja Herramientas avanzadas en el área HERRAMIENTAS DE DESARROLLO . Seleccione el botón Ir → . La consola de Kudu se abre en una nueva pestaña o ventana del navegador.
  10. Usando la barra de navegación en la parte superior de la página, abra la consola de depuración y seleccione CMD .
  11. Seleccione la carpeta LogFiles .
  12. Inspeccione la columna Modificado y seleccione el ícono de lápiz para editar el registro estándar con la última fecha de modificación.
  13. Cuando se abre el archivo de registro, se muestra el error.

Deshabilite el registro stdout cuando se complete la resolución de problemas:

  1. En la Consola de diagnóstico de Kudu , regrese al sitio de ruta wwwroot para revelar el archivo web.config . Abra el archivo web.config nuevamente seleccionando el ícono de lápiz.
  2. Establezca stdoutLogEnabled en false.
  3. Seleccione Guardar para guardar el archivo.

Para obtener más información, vea ASP.NET Core Module .

 Advertencia

Si no se deshabilita el registro stdout, pueden producirse fallas en la aplicación o el servidor. No hay límite en el tamaño del archivo de registro o la cantidad de archivos de registro creados. Solo use el registro stdout para solucionar los problemas de inicio de la aplicación.

Para el registro general en una aplicación ASP.NET Core después del inicio, use una biblioteca de registro que limite el tamaño del archivo de registro y rote los registros. Para obtener más información, consulte proveedores de registro de terceros .

Registro de depuración del módulo principal de ASP.NET (Servicio de aplicaciones de Azure)

El registro de depuración del módulo principal de ASP.NET proporciona un registro adicional más profundo del módulo principal de ASP.NET. Para habilitar y ver registros estándar:

  1. Para habilitar el registro de diagnóstico mejorado, realice una de las siguientes acciones:
    • Siga las instrucciones en Registros de diagnóstico mejorados para configurar la aplicación para un registro de diagnóstico mejorado. Vuelva a implementar la aplicación.
    • Agregue lo que se muestra en los registros de diagnóstico mejorados al archivo web.config de la aplicación en vivo usando la consola Kudu:
      1. Abra Herramientas avanzadas en el área Herramientas de desarrollo . Seleccione el botón Ir → . La consola de Kudu se abre en una nueva pestaña o ventana del navegador.
      2. Usando la barra de navegación en la parte superior de la página, abra la consola de depuración y seleccione CMD .
      3. Abra las carpetas en el sitio de ruta wwwroot . Edite el archivo web.config seleccionando el botón del lápiz. Agregue la sección como se muestra en los registros de diagnóstico mejorados . Selecciona el botón Guardar.
  2. Abra Herramientas avanzadas en el área Herramientas de desarrollo . Seleccione el botón Ir → . La consola de Kudu se abre en una nueva pestaña o ventana del navegador.
  3. Usando la barra de navegación en la parte superior de la página, abra la consola de depuración y seleccione CMD .
  4. Abra las carpetas en el sitio de ruta wwwroot . Si no proporcionó una ruta para el archivo aspnetcore-debug.log , el archivo aparece en la lista. Si proporcionó una ruta, navegue a la ubicación del archivo de registro.
  5. Abra el archivo de registro con el botón de lápiz al lado del nombre del archivo.

Deshabilite el registro de depuración cuando se complete la resolución de problemas:

Para deshabilitar el registro de depuración mejorado, realice una de las siguientes acciones:

  • Retire la del web.config archivo localmente y volver a implementar la aplicación.
  • Use la consola Kudu para editar el archivo web.config y elimine la sección. Guarda el archivo.

Para obtener más información, vea ASP.NET Core Module .

 Advertencia

Si no se deshabilita el registro de depuración, pueden producirse fallas en la aplicación o el servidor. No hay límite en el tamaño del archivo de registro. Solo use el registro de depuración para solucionar los problemas de inicio de la aplicación.

Para el registro general en una aplicación ASP.NET Core después del inicio, use una biblioteca de registro que limite el tamaño del archivo de registro y rote los registros. Para obtener más información, consulte proveedores de registro de terceros .

Aplicación lenta o bloqueada (Servicio de aplicaciones de Azure)

Cuando una aplicación responde lentamente o se cuelga de una solicitud, consulte los siguientes artículos:

Supervisión de cuchillas

Los blades de supervisión proporcionan una experiencia alternativa de solución de problemas a los métodos descritos anteriormente en el tema. Estas cuchillas se pueden usar para diagnosticar errores de la serie 500.

Confirme que las extensiones principales de ASP.NET estén instaladas. Si las extensiones no están instaladas, instálelas manualmente:

  1. En la sección de la hoja HERRAMIENTAS DE DESARROLLO , seleccione la hoja Extensiones .
  2. Las extensiones principales de ASP.NET deberían aparecer en la lista.
  3. Si las extensiones no están instaladas, seleccione el botón Agregar .
  4. Elija las extensiones principales de ASP.NET de la lista.
  5. Seleccione Aceptar para aceptar los términos legales.
  6. Seleccione Aceptar en la hoja Agregar extensión .
  7. Un mensaje emergente informativo indica cuándo las extensiones se han instalado correctamente.

Si el registro estándar no está habilitado, siga estos pasos:

  1. En Azure Portal, seleccione la hoja Herramientas avanzadas en el área HERRAMIENTAS DE DESARROLLO . Seleccione el botón Ir → . La consola de Kudu se abre en una nueva pestaña o ventana del navegador.
  2. Usando la barra de navegación en la parte superior de la página, abra la consola de depuración y seleccione CMD .
  3. Abra las carpetas en el sitio de ruta wwwroot y desplácese hacia abajo para mostrar el archivo web.config en la parte inferior de la lista.
  4. Haga clic en el ícono de lápiz junto al archivo web.config .
  5. Conjunto stdoutLogEnabled a truey cambiar el stdoutLogFile ruta a: \\?\%home%\LogFiles\stdout.
  6. Seleccione Guardar para guardar el archivo web.config actualizado .

Proceda a activar el registro de diagnóstico:

  1. En Azure Portal, seleccione la hoja Registros de diagnósticos .
  2. Seleccione el On interruptor para aplicación de registro (sistema de archivos) y mensajes de error detallados . Seleccione el botón Guardar en la parte superior de la hoja.
  3. Para incluir el seguimiento de solicitudes fallidas, también conocido como registro de búfer de eventos de solicitud fallida (FREB), seleccione el interruptor Activado para el seguimiento de solicitudes fallidas .
  4. Seleccione la hoja de flujo de registro , que se enumera inmediatamente debajo de la hoja de registros de diagnóstico en el portal.
  5. Haz una solicitud a la aplicación.
  6. Dentro de los datos del flujo de registro, se indica la causa del error.

Asegúrese de deshabilitar el registro stdout cuando se complete la resolución de problemas.

Para ver los registros de seguimiento de solicitudes fallidas (registros de FREB):

  1. Vaya a la hoja Diagnosticar y resolver problemas en Azure Portal.
  2. Seleccione Registros de seguimiento de solicitudes fallidas en el área HERRAMIENTAS DE APOYO de la barra lateral.

Consulte la sección Seguimiento de solicitudes fallidas del tema Habilitar el registro de diagnósticos para aplicaciones web en el tema del Servicio de aplicaciones de Azure y las Preguntas frecuentes sobre el rendimiento de la aplicación para Aplicaciones web en Azure: ¿Cómo activo el seguimiento de solicitudes fallidas? para más información.

Para obtener más información, consulte Habilitar el registro de diagnósticos para aplicaciones web en Azure App Service .

 Advertencia

Si no se deshabilita el registro stdout, pueden producirse fallas en la aplicación o el servidor. No hay límite en el tamaño del archivo de registro o la cantidad de archivos de registro creados.

Para el registro de rutina en una aplicación ASP.NET Core, use una biblioteca de registro que limite el tamaño del archivo de registro y rote los registros. Para obtener más información, consulte proveedores de registro de terceros .

Solucionar problemas en IIS

Registro de eventos de aplicación (IIS)

Acceda al registro de eventos de la aplicación:

  1. Abra el menú Inicio, busque el Visor de eventos y luego seleccione la aplicación Visor de eventos .
  2. En el Visor de eventos , abra el nodo Registros de Windows .
  3. Seleccione Aplicación para abrir el Registro de eventos de la aplicación.
  4. Busque errores asociados con la aplicación que falla. Los errores tienen un valor de IIS AspNetCore Module o IIS Express AspNetCore Module en la columna Fuente .

Ejecute la aplicación en el símbolo del sistema

Muchos errores de inicio no producen información útil en el registro de eventos de la aplicación. Puede encontrar la causa de algunos errores ejecutando la aplicación en un símbolo del sistema en el sistema de alojamiento.

Despliegue dependiente del marco

Si la aplicación es una implementación dependiente del marco :

  1. En el símbolo del sistema, navegue a la carpeta de implementación y ejecute la aplicación ejecutando el ensamblaje de la aplicación con dotnet.exe . En el siguiente comando, sustituya el nombre de la asamblea de la aplicación para dotnet .\.dll.
  2. La salida de la consola de la aplicación, que muestra cualquier error, se escribe en la ventana de la consola.
  3. Si se producen errores al realizar una solicitud a la aplicación, realice una solicitud al host y al puerto donde Kestrel escucha. Con el host y la publicación predeterminados, realice una solicitud a http://localhost:5000/Si la aplicación responde normalmente en la dirección del punto final de Kestrel, es más probable que el problema esté relacionado con la configuración del alojamiento y menos probable dentro de la aplicación.

Despliegue autónomo

Si la aplicación es una implementación autónoma :

  1. En el símbolo del sistema, navegue a la carpeta de implementación y ejecute el ejecutable de la aplicación. En el siguiente comando, sustituya el nombre de la asamblea de la aplicación para .exe.
  2. La salida de la consola de la aplicación, que muestra cualquier error, se escribe en la ventana de la consola.
  3. Si se producen errores al realizar una solicitud a la aplicación, realice una solicitud al host y al puerto donde Kestrel escucha. Con el host y la publicación predeterminados, realice una solicitud a http://localhost:5000/Si la aplicación responde normalmente en la dirección del punto final de Kestrel, es más probable que el problema esté relacionado con la configuración del alojamiento y menos probable dentro de la aplicación.

ASP.NET Core Module stdout log (IIS)

Para habilitar y ver registros estándar:

  1. Navegue a la carpeta de implementación del sitio en el sistema de alojamiento.
  2. Si la carpeta de registros no está presente, cree la carpeta. Para obtener instrucciones sobre cómo habilitar MSBuild para crear la carpeta de registros en la implementación automáticamente, consulte el tema Estructura del directorio .
  3. Edite el archivo web.config . Establezca stdoutLogEnabled en truey cambie la ruta stdoutLogFile para que apunte a la carpeta de registros (por ejemplo .\logs\stdout). stdouten la ruta se encuentra el prefijo del nombre del archivo de registro. Una marca de tiempo, identificación de proceso y extensión de archivo se agregan automáticamente cuando se crea el registro. Utilizando stdoutcomo prefijo de nombre de archivo, un archivo de registro típico se denomina stdout_20180205184032_5412.log .
  4. Asegúrese de que la identidad de su grupo de aplicaciones tenga permisos de escritura en la carpeta de registros .
  5. Guarde el archivo web.config actualizado .
  6. Haz una solicitud a la aplicación.
  7. Navega a la carpeta de registros . Encuentre y abra el registro stdout más reciente.
  8. Estudie el registro de errores.

Deshabilite el registro stdout cuando se complete la resolución de problemas:

  1. Edite el archivo web.config .
  2. Establezca stdoutLogEnabled en false.
  3. Guarda el archivo.

Para obtener más información, vea ASP.NET Core Module .

 Advertencia

Si no se deshabilita el registro stdout, pueden producirse fallas en la aplicación o el servidor. No hay límite en el tamaño del archivo de registro o la cantidad de archivos de registro creados.

Para el registro de rutina en una aplicación ASP.NET Core, use una biblioteca de registro que limite el tamaño del archivo de registro y rote los registros. Para obtener más información, consulte proveedores de registro de terceros .

Registro de depuración del módulo principal de ASP.NET (IIS)

Agregue la siguiente configuración del controlador al archivo web.config de la aplicación para habilitar el registro de depuración del módulo principal ASP.NET:

XML

    
  

" style="box-sizing: inherit; font-family: SFMono-Regular, Consolas, "Liberation Mono", Menlo, Courier, monospace; font-size: 1em; direction: ltr; position: relative; border: 0px; display: block; line-height: 19px;"><aspNetCore ...>
  <handlerSettings>
    <handlerSetting name="debugLevel" value="file" />
    <handlerSetting name="debugFile" value="c:\temp\ancm.log" />
  handlerSettings>
aspNetCore>

Confirme que la ruta especificada para el registro existe y que la identidad del grupo de aplicaciones tiene permisos de escritura en la ubicación.

Para obtener más información, vea ASP.NET Core Module .

Habilite la página de excepción de desarrollador

La ASPNETCORE_ENVIRONMENT variable de entorno se puede agregar a web.config para ejecutar la aplicación en el entorno de Desarrollo. Siempre que el entorno no se anule en el inicio de la aplicación UseEnvironmenten el generador de host, la configuración de la variable de entorno permite que aparezca la página de excepción del desarrollador cuando se ejecuta la aplicación.

XML

  
    
  

" style="box-sizing: inherit; font-family: SFMono-Regular, Consolas, "Liberation Mono", Menlo, Courier, monospace; font-size: 1em; direction: ltr; position: relative; border: 0px; display: block; line-height: 19px;"><aspNetCore processPath="dotnet"
      arguments=".\MyApp.dll"
      stdoutLogEnabled="false"
      stdoutLogFile=".\logs\stdout"
      hostingModel="InProcess">
  <environmentVariables>
    <environmentVariable name="ASPNETCORE_ENVIRONMENT" value="Development" />
  environmentVariables>
aspNetCore>

La configuración de la variable de entorno ASPNETCORE_ENVIRONMENTsolo se recomienda para usar en servidores de ensayo y prueba que no están expuestos a Internet. Elimine la variable de entorno del archivo web.config después de la resolución de problemas. Para obtener información sobre cómo establecer variables de entorno en web.config , consulte el elemento secundario environmentVariables de aspNetCore .

Obtener datos de una aplicación

Si una aplicación es capaz de responder a las solicitudes, obtenga la solicitud, la conexión y los datos adicionales de la aplicación utilizando el middleware en línea del terminal. Para obtener más información y código de muestra, vea Solucionar problemas de proyectos de ASP.NET Core .

Aplicación lenta o suspendida (IIS)

Un volcado de bloqueo es una instantánea de la memoria del sistema y puede ayudar a determinar la causa de un bloqueo de la aplicación, falla de inicio o aplicación lenta.

La aplicación se bloquea o encuentra una excepción

Obtenga y analice un volcado del Informe de errores de Windows (WER) :

  1. Cree una carpeta para guardar los archivos de volcado por caída c:\dumpsEl grupo de aplicaciones debe tener acceso de escritura a la carpeta.

  2. Ejecute el script EnableDumps PowerShell :

  3. Ejecute la aplicación en las condiciones que provocan el bloqueo.

  4. Después de que ocurra el bloqueo, ejecute el script DisableDumps PowerShell :

Después de que una aplicación se bloquea y se completa la recopilación de volcados, se permite que la aplicación finalice normalmente. El script de PowerShell configura WER para recopilar hasta cinco volcados por aplicación.

 Advertencia

Los volcados por caída pueden ocupar una gran cantidad de espacio en disco (hasta varios gigabytes cada uno).

La aplicación se bloquea, falla durante el inicio o se ejecuta normalmente

Cuando una aplicación se bloquea (deja de responder pero no se bloquea ), falla durante el inicio o se ejecuta normalmente, consulte Archivos de volcado en modo de usuario: elegir la mejor herramienta para seleccionar una herramienta adecuada para producir el volcado.

Analiza el basurero

Un volcado se puede analizar utilizando varios enfoques. Para obtener más información, consulte Análisis de un archivo de volcado en modo de usuario .

Borrar cachés de paquetes

A veces, una aplicación que funciona falla inmediatamente después de actualizar .NET Core SDK en la máquina de desarrollo o de cambiar las versiones del paquete dentro de la aplicación. En algunos casos, los paquetes incoherentes pueden romper una aplicación cuando se realizan actualizaciones importantes. La mayoría de estos problemas se pueden solucionar siguiendo estas instrucciones:

  1. Elimine las carpetas bin y obj .

  2. Borre las cachés del paquete ejecutando dotnet nuget locals all --cleardesde un shell de comandos.

    La limpieza de cachés de paquetes también se puede lograr con la herramienta nuget.exe y ejecutar el comando nuget locals all -clearnuget.exe no es una instalación incluida con el sistema operativo de escritorio de Windows y debe obtenerse por separado del sitio web de NuGet .

  3. Restaurar y reconstruir el proyecto.

  4. Elimine todos los archivos en la carpeta de implementación en el servidor antes de volver a implementar la aplicación.

Recursos adicionales

Documentación de Azure

Documentación de Visual Studio

Documentación de Visual Studio Code

Fuente: Microsoft.