WebApi { "message": "произошла ошибка" } в IIS7, а не в IIS Express

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

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

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

сообщение. Кто-нибудь знает, что может происходить?

4b9b3361

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

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

238
ответ дан 24 окт. '12 в 6:37
источник

В принципе:

Используйте 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 отошла от стратегии только для IIS, а CustomErrors - это старый skool IIS;).

Во всяком случае, у меня был вопрос о производстве, который у меня не был локально. А потом выяснилось, что я не вижу ошибок на вкладке "Сеть Chrome", как я мог на своей машине dev. В итоге мне удалось решить эту проблему, установив Chrome на моем рабочем сервере, а затем просматривая приложение там на самом сервере (например, на "localhost" ). Затем появились более подробные ошибки со стеком и т.д.

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

GlobalConfiguration.Configuration.IncludeErrorDetailPolicy 
= IncludeErrorDetailPolicy.Always;

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

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

79
ответ дан 20 нояб. '15 в 23:01
источник

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

Это: (в 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;
    }
}
16
ответ дан 26 окт. '17 в 2:39
источник

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

10
ответ дан 15 мая '13 в 10:25
источник

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

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

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

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

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

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

8
ответ дан 19 мая '17 в 11:25
источник

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

Для справок в будущем

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

и

<system.webServer>
  <httpErrors errorMode="Detailed" existingResponse="PassThrough"></httpErrors>
</system.webServer>
6
ответ дан 07 февр. '17 в 0:34
источник