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


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

вот моя паутина.конфигурации

<?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>
26 86

26 ответов:

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

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

<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: функции разработки приложений и выберите ASP.NET 4.5 (или ASP.NET 3.5 если требуется поддержка проектов на платформе .NET Framework 2.0-3.5).
  3. Нажмите кнопку ОК.

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

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

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

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

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

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

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

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

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


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

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

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

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

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

screen shot

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

1.In паутина.Конфигурации

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

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

  • System. Net. Http

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

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

Я настоятельно не рекомендую использовать . Это приводит все запросы (даже .формат JPG. ,стиль CSS. ,PDF и т. д.) будут обрабатываться все зарегистрированные модули http. Есть два отрицательных момента: а) дополнительная нагрузка на аппаратные ресурсы; б) потенциальные ошибки, так как http модули будут обрабатывать новый тип контента.

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

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

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

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

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

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

myserver.myintranet.com/mysite

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

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

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

на основе этого так что ответ, Я просто должен был изменить 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" />

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

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

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

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

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

другой вопрос, но вы никогда не знаете, он может помочь ;)

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

      <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 не найден - модуль фильтрации запросов настроен на отказ расширения файла".

Это так сообщение поможет мне решить эту проблему.

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

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

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

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

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

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

  1. использовать веб-API в один и тот же проект с использованием MVC или формы asp.net

  2. используйте RouteConfig и WebApiConfig в глобальном.эйсакс как GlobalConfiguration.Настроить(WebApiConfig.Реестр); RouteConfig.RegisterRoutes (RouteTable.Маршруты);

  3. использовать RouteConfig для 2 целей, asp.net формы, использующие с friendlyurl и MVC routing для MVC routing

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

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

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

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

мое окончательное решение? Я знаю, что это радикально, но я только что создал новое решение Visual Studio и веб-проект. Выбранный MVC, затем я сделал "Добавить" > "новый элемент", выбрал" Visual C# " > " Web "и" Web Service (ASMX) " под этим. Я скопировал весь мой старый кодовый код, затем я принял к сведению пространство имен, которое он дал новому файлу в моем новом проекте, затем вставил весь мой старый код в новый файл кода в новом проекте и вернул пространство имен к тому, чем оно было. Затем я создал свои папки в своем проекте, который у меня был перед использованием Visual Studio, чтобы сделать "добавить" > "Новая папка", а затем скопировал обратно в Мои файлы в папки из моего другого проекта с помощью Проводника Windows, затем щелкните правой кнопкой мыши каждую папку в Visual Studio и сделал "добавить" > "существующий элемент..."и вытащил элементы в этих папках в папки Visual Studio моего нового проекта. Я снова ссылался на все мои сборки .NET, открыв оба проекта, чтобы я мог сравнить, на какие из них я ссылался ранее (у меня была тонна!). Я должен был назвать свой новый проект немного иначе-в основном я сделал что-то сравнимое с "GeneralWebApp" вместо "MyWebApp", для пример-поэтому мне пришлось сделать "заменить все" во всем моем решении, чтобы заменить это имя, чтобы он получил правильное пространство имен для всех моих файлов. Затем я сделал " перестроить все "в проекте, а затем запустил его с помощью кнопки" Play", которую Visual Studio дает, когда я получил ее для правильной сборки. Это сработало отлично. Поэтому я опубликовал его, и все было в порядке на сервере, где я опубликовал его, когда я запустил его оттуда. У меня нет объяснений тому, что произошло, но именно так я прошел через это. Это неплохой тест просто чтобы увидеть, если что-то Visual Studio делает испортил его.