Все запросы в ASP.NET Web API возвращают ошибку 404

У меня есть веб-сайт ASP.NET MVC 4, который включает веб-API. Сайт разработан и протестирован с помощью Visual Studio 2012 и .NET 4.5 в Windows 8 с IIS Express в качестве веб-сервера. В этой среде разработки все работает.

Теперь он развернут на сервере Windows 2008 R2 (SP1) с IIS 7.5..NET 4.0 и 4.5 установлены. Пул приложений работает с .NET 4.0 в интегрированном режиме конвейера.

В этой производственной среде веб-сайт MVC работает, Web API не работает. Для каждого запроса, независимо от того, GET или POST я получаю ошибку 404. Если я просто введу URL-адрес веб-API в браузере (IE 9, открытый локально на сервере), чтобы запустить GET-запрос, я получаю страницу 404. Если я выдаю запрос POST из клиентского приложения Web API, я получаю также 404 и сообщение:

Не найден ресурс HTTP, который соответствует URI запроса

Я создал тестовый веб-сайт с MVC 4 и веб-API, а также развернул его на одном и том же сервере, и веб-API работает.. Web-API и сборки MVC имеют одинаковый номер версии в обоих проектов.

Кроме того, я добавил в приложение

Для меня это означает, что правильный шаблон маршрута Api/{Controller}/{Id} найден и правильно разобран в контроллер Order и Id=12. Контроллер (полученный из ApiController) существует в веб-сборке, где также находятся все контроллеры MVC.

Однако я не знаю, что может означать состояние 000 и почему не отображается раздел "Выбор маршрута" (что обычно имеет место, даже если сборка не содержит одного ApiController, см. скриншоты на связанной странице выше). Как-то похоже, что ApiController не найден или даже не найден, или поиск не работает молча.

Файлы журнала IIS не показывают ничего полезного. Изменение различных настроек пула приложений и использование одного и того же пула приложений для теста и реального приложения не помогло.

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

Кто-нибудь знает, что может быть проблемой? Также очень приветствуется любая идея отладки или регистрации, чтобы найти причину.

Edit

Благодаря подсказке Даррела Миллера в комментариях ниже я включил Трассировка для ASP.NET Web Api.

Для URL-адреса запроса (GET) http://myserver/api/order/12 я получаю следующее:

В среде разработки успешный (в краткой форме):

Сообщение: http://localhost:50020/api/order/12; Категория: System.Web.Http.Request

Выбор и создание контроллера...

Оператор: DefaultHttpControllerSelector; Операция: SelectController; Сообщение: Route = "controller: order, id: 12"; Категория: System.Web.Http.Controllers

Оператор: DefaultHttpControllerSelector; Операция: SelectController; Сообщение: Заказ; Категория: System.Web.Http.Controllers

Оператор: HttpControllerDescriptor; Операция: CreateController; Сообщение:; Категория: System.Web.Http.Controllers

Оператор: DefaultHttpControllerActivator; Операция: Создать; Сообщение:; Категория: System.Web.Http.Controllers

Оператор: DefaultHttpControllerActivator; Операция: Создать; Сообщение: MyApplication.ApiControllers.OrderController; Категория: System.Web.Http.Controllers

Выбор действия, привязка параметров и вызов действия следуют...

Согласование и форматирование контента для результата...

Оператор: DefaultContentNegotiator; Операция: переговоры; Сообщение: Typ = "String"... более

Утилизация контроллера...

Оператор: OrderController; Операция: Утилизировать; Сообщение:; Категория: System.Web.Http.Controllers

В производственной среде не успешный (в краткой форме):

Сообщение: http://myserver/api/order/12; Категория: System.Web.Http.Request

Оператор: DefaultHttpControllerSelector; Операция: SelectController; Сообщение: Route = "controller: order, id: 12"; Категория: System.Web.Http.Controllers

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

Оператор: DefaultContentNegotiator; Операция: переговоры; Сообщение: Тип = "HttpError"... подробнее

Ответ 1

Благодаря комментарию и исходному коду Кирана Чаллы из этого ответа мне удалось выяснить, что сборка (ReportViewer 11 assembly для служб отчетов SQL Server) отсутствовала на рабочем сервере.

Хотя в этой сборке нет ApiController, похоже, что контроллеры в сборках - в этом случае моя сборка веб-проектов - которые ссылаются на отсутствующую сборку, не найдены.

По-видимому, это поведение связано с этим фрагментом кода из Web API DefaultHttpControllerTypeResolver:

List<Type> result = new List<Type>();

// Go through all assemblies referenced by the application
// and search for types matching a predicate
ICollection<Assembly> assemblies = assembliesResolver.GetAssemblies();
foreach (Assembly assembly in assemblies)
{
    Type[] exportedTypes = null;
    if (assembly == null || assembly.IsDynamic)
    {
        // can't call GetExportedTypes on a dynamic assembly
        continue;
    }

    try
    {
        exportedTypes = assembly.GetExportedTypes();
    }
    catch (ReflectionTypeLoadException ex)
    {
        exportedTypes = ex.Types;
    }
    catch
    {
        // We deliberately ignore all exceptions when building the cache. If 
        // a controller type is not found then we will respond later with a 404.
        // However, until then we don't know whether an exception at all will
        // have an impact on finding a controller.
        continue;
    }

    if (exportedTypes != null)
    {
        result.AddRange(exportedTypes.Where(x => IsControllerTypePredicate(x)));
    }
}

Я не знаю, должно ли это быть так, и я не совсем уверен в комментарии в коде, но этот блок catch ... continue довольно молчал о возможной проблеме, и мне потребовалось огромное количество времени и разочарование, чтобы найти его. Я даже знал, что ReportViewer еще не установлен. Я попытался установить его и зависимые сборки, но он был заблокирован другим запущенным процессом на сервере, поэтому я решил отложить установку до тех пор, пока я не смогу связаться с администратором и не сосредоточиться на тестировании MVC и WebAPI во-первых - большая ошибка! Без фрагмента кода кода Kiran я никогда не думал, что существование ReportViewer.dll может иметь какое-либо отношение к разрешению типа контроллера.

По моему мнению, есть место для улучшения для среднего разработчика, такого как я, у которого нет более глубоких знаний о внутренней работе веб-API.

После установки отсутствующего ReportViewer.dll проблема исчезла.

Вот вопросы о том же симптоме, который может иметь одну и ту же причину:

Edit

Я подал запрос на улучшение в CodePlex:

http://aspnetwebstack.codeplex.com/workitem/1075

Изменить 2 (11 августа 13)

Проблема исправлена для WebAPI v5.0 RC. Подробнее см. Ссылку выше в разделе workitem и его комментариях.

Ответ 2

Большие ресурсы в этом ответе, однако, я получал 404 за то, что оказалось довольно глупой причиной:

Я создал установщик WiX для моего проекта API
Установил его на тестовой виртуальной машине (виртуальной машине)
Запрошен для URI, который должен обслуживать API
BANG! 404: (

Оказалось, что я пропустил упаковку и развернул Global.asax в корень виртуального каталога в моем развертывании. Добавляя это здесь для блаженства, как я:)

Ответ 3

У меня была такая же проблема на удаленном сервере, но при выполнении на локальном хосте отлично работает.

Мое решение было:

<system.webServer>
    <modules>
        <remove name="UrlRoutingModule-4.0" />
        <add name="UrlRoutingModule-4.0" 
            type="System.Web.Routing.UrlRoutingModule" preCondition="" /> 
    </modules>
</system.webServer>

Я надеюсь, что это сработает для вас.