{"Mensaje" de WebApi: "se ha producido un error"} en IIS7, no en IIS Express

Estoy trabajando con ASP.NET MVC 4 WebApi y me divierto mucho ejecutándolo en mi computadora local en IIS Express. También configuré IIS Express para dar servicio a máquinas remotas, por lo que otras personas de mi empresa están usando mi computadora como nuestro servidor web.

Después de decidir que esta era una solución menos que óptima, decidimos colocar el WebApi en un servidor remoto después de instalar .NET 4.5. Cuando uso el violinista y envío una POST a un controlador en mi máquina local, devuelve la respuesta correcta, pero cuando cambio el dominio al servidor web que ejecuta IIS7, la misma POST devuelve un mensaje críptico

{"mensaje": "se ha producido un error"}

mensaje. Alguien tiene alguna idea de lo que podría estar pasando?

El problema era una dependencia faltante que no estaba en el servidor pero estaba en mi máquina local. En nuestro caso, fue un dll Devart.Data.Linq.

Para llegar a esa respuesta, activé el rastreo de IIS para 500 errores. Eso proporcionó un poco de información, pero lo realmente útil fue en la configuración de web.config <system.web><customErrors mode="Off"/></system.web>Esto apuntó a una dependencia cargada dinámicamente que falta. Después de agregar esta dependencia y decirle que se copie localmente, el servidor comenzó a funcionar.

Básicamente:

Use IncludeErrorDetailPolicyen su lugar si CustomErrorsno lo resuelve por usted (por ejemplo, si su pila ASP.NET es> 2012):

GlobalConfiguration.Configuration.IncludeErrorDetailPolicy 
= IncludeErrorDetailPolicy.Always;

Nota: Tenga cuidado al devolver información detallada del error puede revelar información confidencial a los 'hackers'. Vea el comentario de Simon sobre esta respuesta a continuación.

TL; versión DR

Para mí CustomErrorsrealmente no ayudó. Ya estaba configurado en Off, pero todavía recibí un an error has occurredmensaje miserable . Supongo que la respuesta aceptada es de hace 3 años, que es mucho tiempo en la web hoy en día. Estoy usando Web API 2 y ASP.NET 5 (MVC 5) y Microsoft se ha alejado de una estrategia solo de IIS, mientras queCustomErrors es viejo skool IIS;).

De todos modos, tuve un problema en la producción que no tenía localmente. Y luego descubrí que no podía ver los errores en la pestaña Red de Chrome como podía en mi máquina de desarrollo. Al final logré resolverlo instalando Chrome en mi servidor de producción y luego buscando la aplicación allí en el servidor (por ejemplo, en 'localhost'). Luego aparecieron errores más detallados con trazas de pila y todo.

Solo después encontré este artículo de Jimmy Bogard (Nota: ¡Jimmy es el señor AutoMapper! ). Lo curioso es que su artículo también es de 2012, pero en él ya explica que CustomErrorsya no ayuda para esto, pero que PUEDE cambiar el 'Detalle de error' configurando una configuración diferente IncludeErrorDetailPolicyde WebApi global (por ejemplo WebApiConfig.cs):

GlobalConfiguration.Configuration.IncludeErrorDetailPolicy 
= IncludeErrorDetailPolicy.Always;

Afortunadamente, también explica cómo configurarlo para que webapi (2) escuche tu CustomErrorsconfiguración. Es un enfoque bastante sensato, y le permite volver a 2012: P.

Nota: El valor predeterminado es 'LocalOnly', lo que explica por qué pude resolver el problema de la manera que describí, antes de encontrar esta publicación. Pero entiendo que no todo el mundo puede simplemente remotamente a la producción y al inicio de un navegador (sé que en su mayoría no podría hasta que decidí hacerme freelance y DevOps).

Ninguna de las otras respuestas funcionó para mí.

Esto hizo: (en Startup.cs)

public class Startup
{
    public void Configuration(IAppBuilder app)
    {
        var config = new HttpConfiguration();

        WebApiConfig.Register(config);

        // Here: 
        config.IncludeErrorDetailPolicy = IncludeErrorDetailPolicy.Always;
    }
}

(o puede ponerlo en WebApiConfig.cs):

public static class WebApiConfig
{
    public static void Register(HttpConfiguration config)
    {
        // Web API routes
        config.MapHttpAttributeRoutes();

        config.Routes.MapHttpRoute(
            name: "DefaultApi",
            routeTemplate: "api/{controller}/{action}/{id}",
            defaults: new { id = RouteParameter.Optional }
        );

        // Here: 
        config.IncludeErrorDetailPolicy = IncludeErrorDetailPolicy.Always;
    }
}

Siempre llego a esta pregunta cuando llego a un error en el entorno de prueba y recuerdo: "Lo he hecho antes, pero puedo hacerlo directamente en web.config sin tener que modificar el código y volver a implementarlo en el entorno de prueba , pero se necesitan 2 cambios ... ¿qué fue de nuevo? "

Para futura referencia

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

Y

<system.webServer>
  <httpErrors errorMode="Detailed" existingResponse="PassThrough"></httpErrors>
</system.webServer>

Tuve un problema similar al publicar en el punto final de WebAPI. Al desactivar CustomErrors = Off, pude ver el error real, que es uno de los dlls faltantes.

En caso de que esto ayude a alguien:

Tuve un problema similar y, siguiendo las instrucciones de Nates, agregué:

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

Esto me mostró más información sobre el error:

"ExceptionMessage": "No se puede cargar el recurso de metadatos especificado", "ExceptionType": "System.Data.Entity.Core.MetadataException", "StackTrace": "en System.Data.Entity.Core.Metadata.Edm.MetadataArtifactLoaderCompositeResource .LoadResources (...

Esto es cuando recordé que había movido el archivo edmx a una ubicación diferente y me había olvidado de cambiar el nodo de cadenas de conexiones en la configuración (el nodo de cadenas de conexiones se colocó en un archivo separado usando "configSource", pero esa es otra historia).

Mi archivo XML swagger no se implementó en \ bin:

GlobalConfiguration.Configuration
  .EnableSwagger(c =>
  {
    c.SingleApiVersion("v1", "SwaggerDemoApi");
    c.IncludeXmlComments(string.Format(@"{0}\bin\SwaggerDemoApi.XML", 
                         System.AppDomain.CurrentDomain.BaseDirectory));
    c.DescribeAllEnumsAsStrings();
  })

http://wmpratt.com/swagger-and-asp-net-web-api-part-1/

Tenía que establecerse en la Configuración de lanzamiento, así como en la Configuración de depuración.

Si tiene <deployment retail="true"/>en machine.config de .NET Framework, no verá mensajes de error detallados. Asegúrese de que la configuración sea falsa o no esté presente.

Así que probé todas las soluciones sugeridas en vano. Todo lo que hice fue configurar la aplicación desde el servidor y mostró el error completo, esto debería haber funcionado cuando configuré el modo customErrors en falso, pero no fue así. En el momento en que examiné la API del servidor, pude ver el problema.