Веб-API ASP.NET: неописательная внутренняя ошибка сервера 500

После RC эта проблема была исправлена, и вы также будете получать подробную информацию об ошибке, помимо 500 Internal Server Error. (Эта проблема исправлена ​​только для сценариев веб-хостинга).

Вы можете сделать следующее, чтобы получить подробную информацию о фактическом исключении, которое могло произойти во время метода WriteToStream форматировщика.

ObjectContent<IEnumerable<Product>> responseContent = new ObjectContent<IEnumerable<Product>>(db.Products.Include(p => p.ProductSubcategory).AsEnumerable(), new XmlMediaTypeFormatter()); // change the formatters accordingly

            MemoryStream ms = new MemoryStream();

            // This line would cause the formatter's WriteToStream method to be invoked.
            // Any exceptions during WriteToStream would be thrown as part of this call
            responseContent.CopyToAsync(ms).Wait();

Вы можете попробовать добавить:

GlobalConfiguration.Configuration.IncludeErrorDetailPolicy = 
    IncludeErrorDetailPolicy.Always;

на ваш Application_Start() в Global.asax. Это решение работает для многих распространенных ошибок.

Однако, если вы не получаете удовлетворительной информации, вам следует подумать о написании фильтра исключений и его глобальной регистрации.

Эта статья должна помочь вам начать работу. Суть того, что вам нужно, - это написать и зарегистрировать что-то вроде:

public class NotImplExceptionFilter : ExceptionFilterAttribute {
  public override void OnException(HttpActionExecutedContext context) {
     if (context.Exception is NotImplementedException) {
       context.Response = new HttpResponseMessage(HttpStatusCode.NotImplemented);
    }
  }
}

Я столкнулся с этой же проблемой. Я нашел ответ Кирана Чаллы полезным в получении фактического исключения, возникающего вне моего действия.

Чтобы решить мою проблему, установив ProxyCreationEnabled для свойства моего контекста значение false позволило мне сделать еще один шаг вперед.

В моем сценарии следующее исключение было связано с циклической ссылкой в ​​моих моделях. После очистки фантомный 500 отклик пропал. Удачи, если вы еще не решили эту проблему!

Обманчиво простая слабость маршрутизации вызвала эту проблему в моем случае: в моем контроллере Api был еще один HttpPost с той же подписью (не именем). Маршрутизация по умолчанию не разрешила различия имен, и ServiceError 500 был ответом, который он дал до того, как была достигнута какая-либо из функций Api. Решение: измените маршрутизацию по умолчанию или ваши подписи и попробуйте еще раз.

Вот мой RouteConfig.cs, который вполне подходит для стандартного использования WebApi2:

    public class RouteConfig
{
    public static void RegisterRoutes(RouteCollection routes)
    {
        routes.IgnoreRoute("{resource}.axd/{*pathInfo}");

        // Default is required in any case.
        routes.MapRoute(
            name: "Default",
            url: "{controller}/{action}/{id}",
            defaults: new { controller = "Home", action = "Index", id = UrlParameter.Optional }
        );
    }
}

Это может быть связано с циркулярной ссылкой.

http://www.asp.net/web-api/overview/formats-and-model-binding/json-and-xml-serialization#handling_circular_object_references.

Попробуйте добавить следующий код в метод Application_Start в файле Global.asax:

 var json = GlobalConfiguration.Configuration.Formatters.JsonFormatter;
 json.SerializerSettings.PreserveReferencesHandling = Newtonsoft.Json.PreserveReferencesHandling.All;

У меня возникла проблема в RC, когда я не указывал параметры запроса в правильном порядке. Например, если вы укажете $skip=0, будет получено 500, но если вы укажете $orderby=xxx&skip=0, ошибки не будет.

Этот сценарий возник по следующим причинам

1. Проблема возникла из-за неверного формата Web.config. (Несколько разделов конфигурации)

2. Вместо того, чтобы создавать папку roslyn внутри папки bin, я создал ее в корне. (Место развертывания.)

Лучший способ диагностировать это - поместить простую HTML-страницу в местоположение приложения и попытаться просмотреть ее. 500 Описание ошибки будет отображаться на этой html-странице.

А также не забудьте добавить

<customErrors mode="Off"></customErrors>

в Web.config

Я обычно использую Global.asax, чтобы отловить все ошибки. Вот фрагмент кода, который вы можете использовать

public void Application_Error(object sender, EventArgs e)
{
  Exception exc = Server.GetLastError();
  MvcApplication mvcApplication = sender as MvcApplication;
  HttpRequest request = null;
  if (mvcApplication != null) request = mvcApplication.Request;
}

У меня была та же проблема, но ее источник был немного другим: я неправильно установил политику CORS, и это дает мне 500 Internal server error, но поскольку CORS не работал, заголовок Access-Control-Allow-Origin не был представлен в ответ, и браузер не может прочитать фактический отклик

Я решил это с помощью параметра ChromeDevTools Copy as cURL, который позволяет мне видеть ответ и понимать источник ошибки.

Фредрик Нормен написал отличное сообщение в блоге под названием Обработка исключений веб-API ASP.NET по этой теме. В его решении используются настраиваемые классы исключений и атрибут фильтра исключений, который может применяться ко всем ApiController методам действий.