WebApi { "message": "произошла ошибка" } в IIS7, а не в IIS Express
Я работаю с ASP.NET MVC 4 WebApi, и мне очень весело с ним работать на моем локальном компьютере в IIS Express. Я настроил IIS Express для обслуживания удаленных компьютеров, и поэтому другие в моей компании используют мой компьютер в качестве нашего веб-сервера.
После принятия решения о том, что это было менее оптимальное решение, мы решили поместить WebApi на удаленный сервер после установки .NET 4.5. Когда я использую скрипт и отправляю POST на контроллер на моем локальном компьютере, он возвращает правильный ответ, но когда я меняю домен на веб-сервер, на котором запущен IIS7, тот же POST возвращает загадочный
{ "message": "произошла ошибка" }
сообщение. Кто-нибудь знает, что может происходить?
Ответы
Ответ 1
Проблема заключалась в отсутствующей зависимости, которая не была на сервере, но была на моей локальной машине. В нашем случае это была DLL Devart.Data.Linq.
Чтобы получить ответ, я включил трассировку IIS для 500 ошибок. Это дало немного информации, но очень полезная вещь была в настройке web.config <system.web><customErrors mode="Off"/></system.web>
Это указывало на недостающую динамически загруженную зависимость. Добавив эту зависимость и сообщив, что она скопирована локально, сервер начал работать.
Ответ 2
В принципе:
Используйте 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).
Ответ 3
Ни один из других ответов не работал у меня.
Это: (в 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;
}
}
Ответ 4
У меня была аналогичная проблема при отправке в конечную точку WebAPI. Поворачивая CustomErrors = Off, я смог увидеть, что фактическая ошибка, которая является одной из DLL, отсутствовала.
Ответ 5
Я всегда сталкиваюсь с этим вопросом, когда я нахожу ошибку в тестовой среде и помню: "Я делал это раньше, но я могу сделать это прямо в web.config без необходимости изменять код и повторно развертывать тестовая среда, но она принимает 2 изменения... что это было снова?"
Для справок в будущем
<system.web>
<customErrors mode="Off"></customErrors>
</system.web>
и
<system.webServer>
<httpErrors errorMode="Detailed" existingResponse="PassThrough"></httpErrors>
</system.webServer>
Ответ 6
На случай, если это кому-нибудь поможет:
У меня была похожая проблема, и я добавил следующие инструкции Нейтса:
<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", но это другая история).
Ответ 7
Мой файл 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/
![enter image description here]()
Это должно быть установлено в Конфигурации выпуска, а также в Конфигурации отладки.