Страница HTTP 404 не найдена в Web Api, размещенной в IIS 7.5

У меня есть приложение Web Api. Он отлично работает, когда я тестировал его с помощью сервера отладки VS 2010. Но теперь я развернул его в IIS 7.5, и я получаю ошибку HTTP 404 при попытке получить доступ к приложению.

Вот мой web.config

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <connectionStrings>
    <add name="DefaultConnection" connectionString="Data Source=.\SQLEXPRESS;Initial Catalog=aspnet-FlowGearProxy-20123141219;Integrated Security=True" providerName="System.Data.SqlClient" />
  </connectionStrings>
  <appSettings>
    <add key="webpages:Version" value="2.0.0.0" />
    <add key="webpages:Enabled" value="true" />
    <add key="PreserveLoginUrl" value="true" />
    <add key="ClientValidationEnabled" value="true" />
    <add key="UnobtrusiveJavaScriptEnabled" value="true" />
  </appSettings>
  <system.web>
    <compilation debug="true" targetFramework="4.0" />
    <authentication mode="Forms">
      <forms loginUrl="~/Account/Login" timeout="2880" />
    </authentication>
    <pages>
      <namespaces>
        <add namespace="System.Web.Helpers" />
        <add namespace="System.Web.Mvc" />
        <add namespace="System.Web.Mvc.Ajax" />
        <add namespace="System.Web.Mvc.Html" />
        <add namespace="System.Web.Routing" />
        <add namespace="System.Web.WebPages" />
      </namespaces>
    </pages>
  </system.web>
  <system.webServer>
    <validation validateIntegratedModeConfiguration="false" />
    <modules runAllManagedModulesForAllRequests="true" />
  </system.webServer>
</configuration>

Ответ 1

Я тоже боролся с этим. К счастью, Стив Мичелотти задокументировал решение, которое сработало для меня здесь.

В конце дня я включил все глаголы (verb = "*") в обработчик ExtensionlessUrlHandler-Integrated-4.0 в моей веб-конфигурации.

<system.webServer>
    <validation validateIntegratedModeConfiguration="false" />
    <modules runAllManagedModulesForAllRequests="true" />
        <handlers>
            <remove name="ExtensionlessUrlHandler-Integrated-4.0" />
            <add name="ExtensionlessUrlHandler-Integrated-4.0" path="*." verb="*" type="System.Web.Handlers.TransferRequestHandler" resourceType="Unspecified" requireAccess="Script" preCondition="integratedMode,runtimeVersionv4.0" />
        </handlers>
</system.webServer>

Другие отметили, что наличие WebDAV вызывает проблемы. К счастью, я также не столкнулся с этой проблемой.

Ответ 2

Была такая же проблема. Эта настройка конфигурации решила проблему.

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

Как объясняется в http://www.britishdeveloper.co.uk/2010/06/dont-use-modules-runallmanagedmodulesfo.html выше, следует избегать. Используйте это вместо этого. То же решение предоставляется также Lopsided. Держа его здесь, чтобы позволить пользователям избежать реализации первого рабочего решения.

<modules>
  <remove name="UrlRoutingModule-4.0" />
  <add name="UrlRoutingModule-4.0" type="System.Web.Routing.UrlRoutingModule" preCondition="" />
  <!-- any other modules you want to run in MVC e.g. FormsAuthentication, Roles etc. -->
</modules>

Ответ 3

Если IIS установлен или включен после ASP.NET, вам необходимо вручную зарегистрировать ASP.NET с IIS, чтобы ваше приложение .NET работало.

Для Windows 7 и более ранних версий:

  • Запустите командную строку (cmd.exe) в качестве администратора.
  • Перейдите к соответствующему местоположению .NET Framework. (например, C:\Windows\Microsoft.NET\Framework64\v4.0.30319)
  • Запустите aspnet_regiis.exe -i

Для Windows 8 и более поздних версий:

  • В меню "Пуск" введите "Включить или отключить функции Windows" и выберите первый результат.
  • Разверните Internet Information Services: World Wide Web Services: Возможности разработки приложений и выберите ASP.NET 4.5 (или ASP.NET 3.5, если вам нужно поддерживать проекты на .NET Framework 2.0-3.5).
  • Нажмите "ОК".

Ответ 4

Вы используете приложение Web API в виртуальном каталоге или приложении?

Например: у меня была такая же проблема, когда я переместил проект в локальный IIS на веб-сайте по умолчанию > SampleWebAPI. Я полагаю, что это связано с изменением маршрутизации URL следующим образом:

Оригинал: localhost:3092/api/values
Перемещено: localhost/SampleWebAPI/api/values

Если вы переместите проект веб-API на свой собственный веб-сайт, работающий на другом порту, он, похоже, работает.

Дополнительное примечание: я еще больше усложнил проблему, добавив api в качестве псевдонима приложения на моем сайте, что привело к эффективному URL:

localhost:81/api/api/values - заметил это после перемещения веб-сайта на собственный сайт

Поэтому, поскольку я хотел поддерживать разделение между моим сайтом и веб-сайтом проекта api mvc, я изменил правила маршрутизации в global.asax для веб-API "DefaultAPI" от api/{controller}/{id} до {controller}/{id} и ASP.NET MVC один Default от {controller}/{id} до info/{controller}/{id}.

Ответ 5

Это единственный ответ, который сработал у меня...

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


Добавление в файл web.config следующего содержания:

<system.webServer>
  <modules>
    <remove name="UrlRoutingModule-4.0" />
    <add name="UrlRoutingModule-4.0" type="System.Web.Routing.UrlRoutingModule" preCondition="" />
  </modules>
</system.webServer>
Тег system.webServer уже был там, но я добавил к нему тег модулей, а затем удаляю и добавляю теги в тег модулей.

Ответ 6

Несколько вещей, чтобы проверить:

  • Убедитесь, что установлена ​​.NET Framework 4.
  • Убедитесь, что версия 4.NET Framework выбрана для вашего сайта и виртуального каталога (если применимо).
  • Убедитесь, что у вас установлен MVC или имеются соответствующие библиотеки DLL в каталоге bin.
  • Возможно, нужно разрешить расширения веб-сервисов ASP.NET 4.0
  • Поместите приложение в свой собственный пул приложений.
  • Убедитесь, что в каталоге есть как минимум "Сценарии". Права на выполнение.

Ответ 7

У меня была аналогичная проблема. У меня были правильные настройки в моем файле web.config, но был запущен пул приложений в Классическом режиме, а не Интегрированный режим

screen shot

Ответ 8

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

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 для этих сборок

Садиш Кумар .V

Ответ 9

На основе этого SO-ответа мне просто нужно было изменить path="*." на path="*" для добавленного ExtensionlessUrlHandler-Integrated-4.0 в configuration>system.WebServer>handlers в моем web.config

До:

<add name="ExtensionlessUrlHandler-Integrated-4.0" path="*." verb="*" type="System.Web.Handlers.TransferRequestHandler" preCondition="integratedMode,runtimeVersionv4.0" />

После:

<add name="ExtensionlessUrlHandler-Integrated-4.0" path="*" verb="*" type="System.Web.Handlers.TransferRequestHandler" preCondition="integratedMode,runtimeVersionv4.0" />

Ответ 10

Я также столкнулся с этой проблемой. Я решил проблему, перейдя в пулы приложений > Имя пула приложений и изменив .NET Framework с версии v.2.0.50727 на v4.0.30319.

Ответ 11

Мне пришлось отключить параметр публикации файлов "Прекомпилировать во время публикации".

Ответ 12

Существует официальное исправление от Microsoft: http://support.microsoft.com/kb/980368

Я настоятельно НЕ рекомендую использовать < модули runAllManagedModulesForAllRequests = "true" > . Это приводит к тому, что все запросы (даже .jpg,.css,.pdf и т.д.) Будут обрабатываться всеми зарегистрированными модулями HTTP. Есть два отрицательных момента: а) дополнительная нагрузка на аппаратные ресурсы; b) возможные ошибки, поскольку http-модули будут обрабатывать новый тип контента.

Ответ 13

Я начал получать 404 ответа от Web API после выполнения учебника Windows Azure, который сказал мне добавить файл "WebRole.cs" в мой проект.

После удаления "WebRole.cs" из моего проекта мои вызовы Web API снова начали работать.

Ответ 14

Пожалуйста, убедитесь, что пул приложений находится в Интегрированном режиме
Добавьте в файл web.config следующее:

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

Ответ 15

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

myserver.myintranet.com/mysite

Но привязка веб-сайта для http в IIS не имела имени хоста, указанного в привязке. Раньше это работало, и я понятия не имею, как это сдулось.

Как только я положил myserver.myintranet.com в имя хоста, 404 исчез.

В диспетчере IIS вы перейдете в Привязки... в панели действий, а затем отредактируйте привязку http, чтобы указать имя хоста.

Ответ 16

Имела ту же проблему, 404 ответ для веб-api-контроллеров при обслуживании из IIS, но все отлично работало с VS2010. Ни один из вышеперечисленных решений не работал у меня. В конце концов я обнаружил, что проблема в том, что мы добавили поддержку WSE 3.0 для приложения, а в каталоге application/bin отсутствовала dll Microsoft.Web.Services3. Странно, но после копирования dll началось отображение маршрута.

Ответ 17

Не забудьте установить global.asax

Ответ 18

Я тоже боролся с этим. Моя точная проблема заключалась в том, что у меня был веб-сервис ASMX, который, когда я вводил параметр в веб-метод и проверял его, давал мне 404. Конкретный метод работал хорошо в прошлом и не был изменен, только переиздан. Тогда я попал сюда и попробовал все опубликованные ответы, и ничего не помогло.

Мое окончательное решение? Я знаю, что это радикально, но я только что создал новое решение Visual Studio и веб-проект. Выбрал MVC, затем я сделал "Add"> "New Item", выбрал "Visual С#"> "Web" и "Web Service (ASMX)" под этим. Я скопировал весь свой старый код с выделенным кодом, затем принял к сведению пространство имен, которое дало новый файл в моем новом проекте, затем вставил весь свой старый код в новый файл с выделенным кодом в новом проекте и поместил пространство имен вернуться к тому, что было.

Затем я создал свои папки в своем проекте, которые у меня были до того, как с помощью Visual Studio выполнить команду "Добавить"> "Новая папка", затем скопировал обратно свои файлы в папки из моего другого проекта с помощью проводника Windows, затем щелкнул правой кнопкой мыши каждую папку в Visual Studio и сделал "Добавить"> "Существующий элемент..." и перетащил элементы из этих папок в папки моего нового проекта Visual Studio. Я снова сослался на все свои сборки .NET, открыв оба проекта, чтобы я мог сравнить, на какие из них я ссылался ранее (их было несколько). Я должен был назвать свой новый проект немного по-другому - в основном я сделал что-то сравнимое с "GeneralWebApp" вместо "MyWebApp", например - поэтому мне пришлось сделать "Заменить все" во всем моем решении, чтобы заменить это имя, так что это получить правильное пространство имен для всех моих файлов.

Затем я выполнил "Rebuild All" в проекте, а затем запустил его с помощью кнопки "Play", которую выдает Visual Studio, когда я получил его для правильной сборки. Работало нормально. Поэтому я опубликовал его, и все было нормально на сервере, где я его опубликовал, когда я запускал его оттуда. У меня нет никаких объяснений относительно того, что случилось, но как я это пережил. Это не плохой тест, просто чтобы увидеть, испортил ли что-то Visual Studio.

Ответ 19

Для меня проблема была в том, что корневой сайт был настроен для использования пула приложений .NET 2.0, и моим приложением на этом сайте было .NET 4.5.

Я создал новый сайт с пулом приложений .NET 4 и поместил свое приложение в корень этого - и это работало нормально.

Ответ 20

Какой HTTP-запрос вы делаете?

Это слегка левый ответ, но вы попытались удалить страницу ошибки по умолчанию IIS для 404, чтобы проверить, что ваш API действительно возвращается?

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

Другая проблема, но вы никогда не знаете, что это может помочь;)

Ответ 21

Эта часть конфигурации в файле web.config может помочь мне в этом: в разделе system.webServer:

      <security>
          <requestFiltering>
              <verbs applyToWebDAV="true">
                  <remove verb="PUT" />
                  <add verb="PUT" allowed="true" />
                  <remove verb="DELETE" />
                  <add verb="DELETE" allowed="true" />
                  <remove verb="PATCH" />
                  <add verb="PATCH" allowed="true" />
              </verbs>
          </requestFiltering>
      </security>      

Ответ 22

Недавно у меня было 404 не найдена ошибка со всеми моими маршрутами/контроллерами Web Api 2. Поэтому я пошел на фактический сервер и попытался просмотреть с помощью localhost вместо имени хоста и получил "404.7 Not Found". Модуль фильтрации запросов настроен на отказ в расширении файла ".

Эта публикация поможет мне решить ее.

Ответ 23

Это разрешилось для меня, когда я устанавливаю флажок для UrlRoutingModule-4.0:

Диспетчер IIS > Модули > выберите UrlRoutingModule-4.0 > Модуль редактирования > установите флажок "Вызовы только для запросов к приложениям ASP.NET или управляемым обработчикам".

Ответ 24

У меня была такая же проблема: на недавно установленной машине с Visual Studio 2013 проект web-api работал под IISExpress, но не под локальным IIS. Я пробовал все, что мог найти, но в конце концов проблема не была необходима для веб-API, но с MVC: даже она была установлена, ни один проект MVC не запускался.

Что сработало для меня - это удалить IIS (из ADD/REMOVE Windows Features), затем переустановить его, а затем запустить aspnet_regiis -i. Может быть, это помогает кому-то другому.

Ответ 25

Я потратил много времени на то, чтобы попробовать много чего, наконец, понять, что добавляю свое веб-приложение не в Сайты/Веб-сайты по умолчанию, а на другом веб-узле, привязанном к другому порту. Очевидно, что попытка localhost на порту 80 дала бы 404.

Ответ 26

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

  • Использовать Web Api в том же проекте, используя формы MVC или asp.net

  • Использовать RouteConfig и WebApiConfig в Global.asax в виде       GlobalConfiguration.Configure(WebApiConfig.Register);       RouteConfig.RegisterRoutes(RouteTable.Routes);

  • Использовать RouteConfig для двух целей, формы asp.net, используя с маршрутизацией friendlyurl и mvc для маршрутизации MVC

мы просто используем этот тег в web.config, он будет работать.

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

Ответ 27

Столкнулся с той же проблемой с веб-API и .Net Core Web API. Хорошо работал в VS 2017 во время отладки, но вернул 404 при публикации в IIS 7.5. Решением для меня было изменить способ создания сайта. Вместо публикации в корне веб-сайта (созданного путем щелчка правой кнопкой мыши Сайты... Добавить веб-сайт) мне пришлось создать приложение (созданное путем щелчка правой кнопкой мыши веб-сайта... Добавить приложение) и опубликовать его в этой папке. Обратите внимание, что для версии Core мне пришлось изменить настройку версии пула приложений .NET Framework на "No Managed Code".

Ответ 28

Для меня решение было удалить следующие строки из моего файла web.config:

<dependentAssembly>
    <assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-4.1.1.3" newVersion="4.1.1.3" />
</dependentAssembly>
<dependentAssembly>
    <assemblyIdentity name="Microsoft.IdentityModel.Tokens" publicKeyToken="31bf3856ad364e35" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-5.5.0.0" newVersion="5.5.0.0" />
</dependentAssembly>

Я заметил, что VS добавил их автоматически, не знаю почему