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


96

У меня есть приложение 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>

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

>> с использованием отладочного сервера VS 2010. - АКА злой Кассини. См. Blogs.msdn.com/b/rickandy/archive/2011/04/22/… - Если это не сработает, создайте новое приложение MVC 4 WebApi и протестируйте развертывание - просто
RickAndMSFT

Ответы:


93

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

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


3
+1 для этого. Но я изменил его в сопоставлениях обработчиков в приложении с помощью диспетчера IIS. Он был включен для набора глаголов. Я изменил это на все глаголы (*) и вуаля. Но всегда лучше указывать источник.
Wolf5

1
У меня та же проблема, но эти изменения мне не помогли. Есть ли другая конфигурация? Или может быть ссылка на библиотеку? См. Также: stackoverflow.com/questions/27303523/…
Бабак

2
многие люди говорят, что использование runAllManagedModulesForAllRequests повлияет на производительность (см. ответы hemant gautam ниже). Однако я не могу заставить ту же службу работать, поэтому я следую конфигурации здесь: blog.maartenballiauw.be/post/2012/12/07/… Эта ссылка также указывает на то, что включение WebDAV также может повлиять на результат
Хоанг Лонг,

Отличный ответ!
EnocNRoll - AnandaGopal Pardue

1
Для меня глагол уже был *. Мне также пришлось изменить путь, чтобы *он работал, поскольку *.проблема все еще вызывала
Альсти

56

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

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

Работает нормально, но это не очень хорошее решение. Лучше использовать UrlRoutingModule (см. Ответ Lopsided ниже). britishdeveloper.co.uk/2010/06/…
Der_Meister

37

Если 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. Щелкните ОК.

2
Я перешел с IIS Express для разработки на полноценный IIS, и это исправило его для меня. Спасибо!
Джим Браун

1
Подобно @JimBrown выше; это сработало для меня после перехода с IIS Express.
SolidRegardless 03 фев.15,

Это решило это для меня. В Windows 7 Visual Studio 2015 Ent, новый веб-сайт MVC 5, был изменен с IIS Express на полноценный IIS.
Джефф Гюнтер

26

Вы запускаете приложение веб-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}.


3
хехехе ... Я назвал мое приложение в IISкачестве apiтоже. Это вызвало всю эту отладку методом проб и ошибок более 2 часов. Большое спасибо за то, что поделились своим опытом! Переименовал его, и теперь я снова вернулся к делу. : D
Лениэль Маккаферри

Спасибо - это была моя проблема! :)
Джен

Я не уверен, почему вызовы api не работают, когда я размещал свой проект под портом 8080, просто переместив его как виртуальный каталог на веб-сайт по умолчанию, помогло :)
Kiran

14

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

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


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


Ударьте эту проблему на сервере 2008 (не R2), и это было единственное решение, которое сработало для меня. Кроме того, мне пришлось совместить это с установкой пула приложений в «интегрированный» режим.
Zoomzoom

11

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

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

У меня есть 4 других обычных веб-приложения, работающих на том же сервере IIS, и все они используют .NET framework 4. Итак, какие из этих 4 пунктов не нужны? когда я опубликовал свое приложение mvc, я добавил добавляемые развертываемые зависимости и добавил ASP.NET MVC, так что он находится в моем каталоге bin
Armand

@Armand Похоже, вы сделали №1. №2 все еще необходим. Добавление развертываемых зависимостей, если вы сделали это, как описано здесь: haacked.com/archive/2011/05/25/bin-deploying-asp-net-mvc-3.aspx , должно решить проблему № 3 выше. №4 может понадобиться, а может и нет, хотя у меня нет знаний, чтобы сказать вам, когда он нужен, а когда нет.
Joe Schrag

9

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

Скриншот


7

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

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

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


Эти DLL необходимы, если на сервере не установлен MVC. В моем случае я видел пустую страницу при попытке вызвать API. Добавление DLL вручную сработало для меня. Спасибо!!
Vipul bhojwani 09

Моя проблема была решена после добавления System.Net.Http в основную папку публикации, моим было решение Asp.net Core
mohas

6

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

Большое спасибо, Грег, я собирался убить меня из-за этого глупого пути = "*." но теперь, после того, как отбросил эту жалкую точку, все работает отлично! Большое спасибо!
Юниор Сильва

5

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


1
Я тоже это обнаружил. Поддерживаю свой ответ, потому что его легко пропустить. Когда я создал сайт для своего приложения, IIS автоматически создал для меня пул приложений с .NET v2.0 !! Почему, почему, почему ?? :)
Майк Таверн

3

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


И где ты это делаешь?
vapcguy 09

1
Он находится в диалоговом окне, которое появляется, когда вы щелкаете проект правой кнопкой мыши и выбираете «Опубликовать». Выглядит это так
Пакман

3

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

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


1
Спасибо так много! Я перепробовал абсолютно все остальное, и это единственное, что исправило.
Оран Деннисон

То же самое, большое спасибо за добавление этого ответа! Было решение моей проблемы!
Октавио Гарбарино

2

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

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


Это сработало для меня. Я перенес приложение Azure обратно в развертывание виртуальной машины, и после того, как я закомментировал содержимое WebRole.cs, мои вызовы WebAPI снова начали работать.
Скотт

Я, должно быть, потратил на это день! Комментирование WebRole.cs сработало - интересно, почему, однако?
Игорек

2

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

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

2

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

myserver.myintranet.com/mysite

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

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

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


Даже я тоже сталкиваюсь с той же проблемой. и, как вы предложили, я проверил имя хоста в привязке http, и он только правильно обновился. Но все же моя проблема сохраняется. Примечание. Я разместил свое приложение API как дочернее приложение. Пожалуйста, подскажите, есть ли у кого-нибудь идеи по этому поводу. пример: «sample.example.com» - мое основное приложение, и в этом домене был создан API под именем «sample.example.com/myAPI/»
Кришна Мани


1

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


1

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

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


1

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

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

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

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


1

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


0

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

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

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

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


0

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

0

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

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


0

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

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


0

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

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


0

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


0

Я ничего не делаю, просто добавляю этот тег в 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>

0

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


0

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


0

Попробуйте этот 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>
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.