Приложение ASP.NET Web API дает 404 при развертывании в IIS 7

У меня есть ASP.NET Web API, который отлично работает при работе на "IIS Express" с localhost: 1783

Settings in VS

Но когда я пересекаю "Использовать IIS Express", а затем нажмите "Создать виртуальный каталог"...

New settings

... Я просто получаю 404 ошибки: The 404 error

Любые идеи в чем-то не так? Спасибо!

ОТВЕТЫ

Ответ 1

Пока отмеченный ответ заставляет его работать, все, что вам действительно нужно добавить в webconfig, это:

    <handlers>
      <!-- Your other remove tags-->
      <remove name="UrlRoutingModule-4.0"/>
      <!-- Your other add tags-->
      <add name="UrlRoutingModule-4.0" path="*" verb="*" type="System.Web.Routing.UrlRoutingModule" preCondition=""/>
    </handlers>

Обратите внимание, что ни один из них не имеет определенного порядка, хотя вы хотите, чтобы его удаляли перед добавлением.

Причина, по которой мы получаем 404, заключается в том, что модуль маршрутизации Url запускается только для корня веб-сайта в IIS. Добавив модуль в эту конфигурацию приложения, у нас есть модуль для запуска под этим пуском приложений (ваш путь к подкаталогу), и модуль маршрутизации запускается.

Ответ 2

Для меня, помимо наличия runAllManagedModulesForAllRequests="true", мне также пришлось отредактировать "path" атрибут ниже. Раньше мой атрибут пути был "*.", что означает, что он выполняется только на url, содержащем точку персонаж. Однако мой URL-адрес приложения не содержит точки. Когда я переключил путь на "*", тогда он сработал. Вот что у меня сейчас:

  <system.webServer>
      <validation validateIntegratedModeConfiguration="false" />
      <modules runAllManagedModulesForAllRequests="true">
      <remove name="WebDAVModule"/>
      </modules>

      <handlers>
          <remove name="WebDAV" />
          <remove name="ExtensionlessUrlHandler-ISAPI-4.0_32bit" />
          <remove name="ExtensionlessUrlHandler-ISAPI-4.0_64bit" />
          <remove name="ExtensionlessUrlHandler-Integrated-4.0" />
          <add name="ExtensionlessUrlHandler-ISAPI-4.0_32bit" path="*" verb="*" modules="IsapiModule" scriptProcessor="%windir%\Microsoft.NET\Framework\v4.0.30319\aspnet_isapi.dll" preCondition="classicMode,runtimeVersionv4.0,bitness32" responseBufferLimit="0" />
          <add name="ExtensionlessUrlHandler-ISAPI-4.0_64bit" path="*" verb="*" modules="IsapiModule" scriptProcessor="%windir%\Microsoft.NET\Framework64\v4.0.30319\aspnet_isapi.dll" preCondition="classicMode,runtimeVersionv4.0,bitness64" responseBufferLimit="0" />
          <add name="ExtensionlessUrlHandler-Integrated-4.0" path="*" verb="*" type="System.Web.Handlers.TransferRequestHandler" preCondition="integratedMode,runtimeVersionv4.0" />
      </handlers>
  </system.webServer>

Ответ 3

Вам может потребоваться установить исправление KB980368.

В этой статье описывается обновление, которое позволяет определенным обработчикам IIS 7.0 или IIS 7.5 обрабатывать запросы, чьи URL-адреса не заканчиваются периодом. В частности, эти обработчики отображаются на "." запросить пути. В настоящее время обработчик, который отображается на "." request path обрабатывает только запросы, URL-адреса которых заканчиваются периодом. Например, обработчик обрабатывает только запросы, URL-адреса которых похожи на следующий URL-адрес:

http://www.example.com/ExampleSite/ExampleFile.

После применения этого обновления обработчики, сопоставленные с символом "*." request path может обрабатывать запросы, URL-адреса которых заканчиваются периодом и запросы, URL-адреса которых не заканчиваются периодом. Например, обработчик теперь может обрабатывать запросы, которые похожи на следующие URL-адреса:

http://www.example.com/ExampleSite/ExampleFile

http://www.example.com/ExampleSite/ExampleFile.

После применения этого патча приложения ASP.NET 4 могут обрабатывать запросы для URL-адресов без расширения. Таким образом, будут выполняться управляемые HttpModules, которые выполняются до выполнения обработчика. В некоторых случаях HttpModules может возвращать ошибки для URL-адресов без расширения. Например, HttpModule, который был написан для ожидания только запросов .aspx, может теперь возвращать ошибки, когда он пытается получить доступ к свойству HttpContext.Session.

Ответ 4

Эта проблема также может возникнуть из-за следующих

1. В Web.Config

<system.webServer>
     <modules runAllManagedModulesForAllRequests="true" /> 
</system.webServer>

2. Убедитесь, что в папке bin на сервере, где развертывается веб-API, доступны следующие файлы.

• System.Net.Http

• System.Net.Http.Formatting

• System.Web.Http.WebHost

• System.Web.Http

Эти сборки не будут копироваться в папку bin по умолчанию, если публикация осуществляется через Visual Studio, поскольку пакеты веб-API устанавливаются через Nuget на машине разработки. Тем не менее, если вы хотите, чтобы эти файлы были доступны как часть публикации Visual Studio, вам необходимо установить CopyLocal в True для этих сборок

Ответ 6

У меня была такая же проблема. большая часть R & D я нашел проблему.

но пока ваша конфигурация finne означает, что Aspnet 64 бит и IIS хорошо, тогда единственная проблема, которую я видел, - это путь "web api, который использует локальный путь directiry", так что вам нужно его жаждать. подобным образом. ~../../../api/products/

Большое спасибо за публикацию проблемы. я склонялся alt abt iis и другие настройки в файле конфигурации.

Ответ 7

Я использую Visual Studio 2012, загружаю и устанавливаю обновление 2, выпущенное Microsoft недавно (по состоянию на 4/2013).

Обновление Visual Studio 2012 2

В этом обновлении есть некоторые исправления ошибок.

Ответ 8

Я пару дней боролся с этой проблемой, пытаясь предложить всевозможные вещи. Моя машина Dev работала нормально, но новая машина, которую я развертывал, давала мне ошибку 404.

В диспетчере IIS я сравнил сопоставления обработчиков на обеих машинах, чтобы понять, что многие обработчики отсутствовали. Оказывается, что ASP.Net 5 не был установлен на машине.

Ответ 9

Для меня эта проблема несколько отличалась от других ответов, поскольку я получал только 404 на OPTIONS, но у меня уже были ОПЦИИ, конкретно указанные в моих встроенных параметрах обработчика URL-адресов без расширения. Очень запутанно.

  • Как утверждали другие, runAllManagedModulesForAllRequests = "true" в модули node - это простой способ обмануть большинство проблем веб-API 404, хотя я предпочитаю отвечать на @DavidAndroidDev, который гораздо менее навязчив. Но в моем случае было что-то дополнительное.
  • К сожалению, у меня был этот набор в IIS при фильтрации запросов на сайте:

ОПЦИИ Проблема с фильтрацией запросов

Добавив в web.config следующую безопасность node, необходимо было отключить этот полный системный .webserver, включенный для контекста:

  <system.webServer>
    <modules runAllManagedModulesForAllRequests="true">
      <remove name="WebDAVModule" />
    </modules>
    <handlers>
      <remove name="ExtensionlessUrlHandler-Integrated-4.0" />
      <remove name="OPTIONSVerbHandler" />
      <remove name="TRACEVerbHandler" />
      <remove name="WebDAV" />
      <add name="ExtensionlessUrlHandler-Integrated-4.0" path="*." verb="*" type="System.Web.Handlers.TransferRequestHandler" preCondition="integratedMode,runtimeVersionv4.0" />
    </handlers>
    <security>
      <requestFiltering>
        <verbs>
          <remove verb="OPTIONS" />
        </verbs>
      </requestFiltering>
    </security>
  </system.webServer>

Хотя это не идеальный ответ на этот вопрос, это первый результат для "IIS OPTIONS 404" в Google, поэтому я надеюсь, что это поможет кому-то; стоил мне часа сегодня.

Ответ 10

Для меня я получил ошибку 404 на своих сайтах НЕ используя IIS Express (используя локальный IIS) во время запуска приложения, использующего IIS Express. Если бы я закрыл браузер, который использовался для запуска IIS Express, тогда 404 исчезнет. Для меня у меня был проект IIS Express, вызывающий локальные службы IIS, поэтому я преобразовал проект IIS Express для использования Local IIS, а затем все сработало. Похоже, что по какой-то причине вы не можете запускать как веб-сайт IIS Express, так и локальный веб-сайт IIS.