Страница HTTP 404 не найдена в веб-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>

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

В конце дня я включил все команды (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 вызывает проблемы. К счастью, я тоже не столкнулся с этой проблемой.

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

<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>

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

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

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

Для Windows 8 и новее:

1. В меню «Пуск» введите «Включение или отключение компонентов Windows» и выберите первый результат.
2. Разверните Internet Information Services: World Wide Web Services: Application Development Features и выберите ASP.NET 4.5 (или ASP.NET 3.5, если вам нужно поддерживать проекты на .NET Framework 2.0-3.5).
3. Щелкните ОК.

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

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

Оригинал: localhost:3092/api/values
перенесено: localhost/SampleWebAPI/api/values

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

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

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

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

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

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

• Переполнение стека - диагностика ошибок 404 в IIS 7 и ASP.NET MVC

У меня сработало добавление следующего в файл 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, конечно, уже был там, но я добавил к нему тег модулей, а затем удалил и добавил теги в тег модулей.

Несколько вещей, которые нужно проверить:

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

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

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

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

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

На основе этого 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" />

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

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

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

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

Я начал получать 404 ответа от веб-API после того, как изучил руководство по Windows Azure, в котором мне предлагалось добавить файл «WebRole.cs» в мой проект.

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

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

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

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

myserver.myintranet.com/mysite

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

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

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

Не забудьте развернуть global.asax

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

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

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

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

Мое окончательное решение? Я знаю, что это решительно, но я только что создал новое решение Visual Studio и веб-проект. Выбрал MVC, затем сделал «Добавить»> «Новый элемент», выбрал «Visual C #»> «Веб» и «Веб-сервис (ASMX)» под ним. Я скопировал весь свой старый код программной части, затем обратил внимание на пространство имен, которое он дал новому файлу в моем новом проекте, затем вставил весь мой старый код в новый файл кода программной части в новом проекте и поместил пространство имен назад к тому, что было.

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

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

Если вы поместите в IIS только папку bin (после сборки проекта), возникнет и эта проблема. В этой ситуации вы должны опубликовать проект с помощью VisualStudio, а затем поместить опубликованную папку в IIS.

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

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

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

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

Эта часть конфигурации в файле 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>      

Недавно у меня была ошибка 404 not found со всеми моими маршрутами / контроллерами Web Api 2. Итак, я зашел на реальный сервер и попытался просмотреть, используя localhost вместо имени хоста, и получил «404.7 Not Found - модуль фильтрации запросов настроен на запрет расширения файла».

Этот пост ТАК поможет мне решить эту проблему.

Это было решено для меня, когда я включил флажок для UrlRoutingModule-4.0:

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

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

Что сработало для меня, так это удалить IIS (из ДОБАВИТЬ / УДАЛИТЬ компоненты Windows), затем переустановить его, а затем запустить aspnet_regiis -i. Может быть, это кому-то поможет.

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

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

1. Используйте Web Api в одном проекте с помощью форм MVC или asp.net

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

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

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

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

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

Для меня решение заключалось в удалении следующих строк из моего файла 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 добавил их автоматически, не знаю почему.

Попробуйте этот webconfg .. замените "NewsApi.dll" своей основной dll!

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <location path="." inheritInChildApplications="false">
    <system.webServer>
      <handlers>
        <add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModule" resourceType="Unspecified" />
      </handlers>
      <aspNetCore processPath="dotnet" arguments=".\NewsApi.dll" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" />
    </system.webServer>
  </location>
</configuration>