{«Сообщение» WebApi: «произошла ошибка»} в IIS7, а не в IIS Express

Я работаю с ASP.NET MVC 4 WebApi и мне очень нравится запускать его на моем локальном компьютере в IIS Express. Я также настроил IIS Express для обслуживания удаленных компьютеров, поэтому другие сотрудники моей компании используют мой компьютер в качестве нашего веб-сервера.

После того, как мы решили, что это решение не является оптимальным, мы решили разместить WebApi на удаленном сервере после установки .NET 4.5. Когда я использую fiddler и отправляю POST на контроллер на моем локальном компьютере, он возвращает правильный ответ, но когда я меняю домен на веб-сервер под управлением IIS7, тот же POST возвращает загадочный

{"message": "произошла ошибка"}

сообщение. У кого-нибудь есть идеи, что может происходить?

Проблема заключалась в отсутствующей зависимости, которая отсутствовала на сервере, но была на моей локальной машине. В нашем случае это была библиотека Devart.Data.Linq.

Чтобы получить такой ответ, я включил трассировку IIS для 500 ошибок. Это дало немного информации, но действительно полезно было установить в web.config параметр <system.web><customErrors mode="Off"/></system.web>This, указывающий на отсутствующую динамически загружаемую зависимость. После добавления этой зависимости и указания на ее локальное копирование сервер начал работать.

В принципе:

IncludeErrorDetailPolicyВместо этого используйте, если CustomErrorsэто не решает для вас (например, если вы используете ASP.NET> 2012):

GlobalConfiguration.Configuration.IncludeErrorDetailPolicy 
= IncludeErrorDetailPolicy.Always;

Примечание. Будьте внимательны, возвращая подробную информацию об ошибке, которая может раскрыть конфиденциальную информацию хакерам. См. Комментарий Саймона к этому ответу ниже.

TL; DR версия

Для меня CustomErrorsэто не очень помогло. Это было уже установлено Off, но я все еще получил только жалкое an error has occurredсообщение. Я предполагаю, что принятый ответ от 3 лет назад, который является долгое время в веб-слове в настоящее время. Я использую Web API 2 и ASP.NET 5 (MVC 5), и Microsoft отошла от стратегии, CustomErrorsоснованной только на IIS, в то время как старый skool IIS;).

В любом случае, у меня была проблема с производством, которой у меня не было на месте. А потом обнаружил, что не вижу ошибок на вкладке «Сеть» Chrome, как на своей машине разработчика. В конце концов мне удалось решить эту проблему, установив Chrome на свой производственный сервер и затем перейдя к приложению на самом сервере (например, на «localhost»). Потом появились более подробные ошибки со следами стека и все.

Только после этого я нашел эту статью от Джимми Богарда (Примечание: Джимми - мистер AutoMapper! ). Самое смешное, что его статья также написана в 2012 году, но в ней он уже объясняет, что CustomErrorsэто больше не помогает, но что вы МОЖЕТЕ изменить « IncludeErrorDetailPolicyСведения об ошибках», установив другое в глобальной конфигурации WebApi (например WebApiConfig.cs):

GlobalConfiguration.Configuration.IncludeErrorDetailPolicy 
= IncludeErrorDetailPolicy.Always;

К счастью, он также объясняет, как настроить, чтобы webapi (2) слушал ваши CustomErrorsнастройки. Это довольно разумный подход, и это позволяет вам вернуться к 2012 году: P.

Примечание. Значение по умолчанию - «LocalOnly», что объясняет, почему я смог решить проблему так, как я описал, до нахождения этого поста. Но я понимаю, что не все могут просто подключиться к производству и запустить браузер (я знаю, что в основном не мог, пока не решил заняться фрилансом и DevOps).

Ни один из других ответов не работал для меня.

Это сделал: (в Startup.cs)

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

        WebApiConfig.Register(config);

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

(или вы можете поместить его в 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;
    }
}

Я всегда прихожу к этому вопросу, когда сталкиваюсь с ошибкой в ​​тестовой среде и вспоминаю: «Я делал это раньше, но я могу сделать это прямо в web.config без необходимости изменять код и повторно развертывать в тестовой среде. , но требуется 2 изменения ... что это было снова? "

Для дальнейшего использования

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

И

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

У меня была похожая проблема при публикации в конечной точке WebAPI. Повернув CustomErrors = Off, я смог увидеть фактическую ошибку, которая отсутствовала в одной из библиотек.

На случай, если это кому-нибудь поможет:

У меня была похожая проблема, и я добавил следующие инструкции Нейтса:

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

Это показало мне больше информации об ошибке:

«ExceptionMessage»: «Невозможно загрузить указанный ресурс метаданных.», «ExceptionType»: «System.Data.Entity.Ceta.MetadataException», «StackTrace»: «at System.Data.Entity.Core.Metadata.Edm.MetadataArtifactLoaderCompositeRo .LoadResources (...

В этот момент я вспомнил, что переместил файл edmx в другое место и забыл изменить узел строк соединений в конфигурации (узел соединений был помещен в отдельный файл с использованием «configSource», но это уже другая история).

Мой файл swagger XML не был развернут в \ 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/

Это должно быть установлено в Конфигурации выпуска, а также в Конфигурации отладки.

Если <deployment retail="true"/>в вашем компьютере .NET Framework есть файл machine.config, вы не увидите подробных сообщений об ошибках. Убедитесь, что параметр имеет значение false или отсутствует.

Поэтому я попробовал все предложенные решения безрезультатно. Все, что я сделал, это установил запуск приложения с сервера, и он отображал ошибку полностью, это должно было сработать, когда я установил режим customErrors в false, но это не так. В тот момент, когда я просматривал API-интерфейс сервера, я смог увидеть проблему.