Страница 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 ответов:
Я тоже боролся с этим. К счастью, Стив Микелотти задокументировал решение, которое сработало для меня здесь.
в конце дня я включил все глаголы (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 и более ранних версий:
- Запустите командную строку (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).
- Нажмите кнопку ОК.
вы используете приложение 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 oneDefaultС{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>
несколько вещей, чтобы проверить:
- убедитесь, что у вас установлена платформа .NET Framework 4.
- убедитесь, что версия 4 платформы .NET Framework выбрана для вашего веб-сайта и виртуального каталога (если применимо).
- убедитесь, что у вас установлен MVC или есть соответствующие DLL в вашем каталоге bin.
- возможно, потребуется разрешить ASP.NET 4.0 расширения веб-службы
- поставить приложение в свой собственный пул приложений.
- убедитесь, что каталог имеет по крайней мере "только Скрипты" разрешения на выполнение.
У меня была похожая проблема. У меня правильные настройки в web.конфигурационный файл, но запускал пул приложений в классический режим, а не встроенный режим
эта проблема также может произойти из-за следующего
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 снова начали работать.
пожалуйста, убедитесь, что пул приложений в встроенный режим
И добавьте следующее в интернете.конфигурационный файл:<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, отображение маршрута начал работать.
какой 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.конфиг, его работа этот вопрос возникает один из следующих моментов
использовать веб-API в один и тот же проект с использованием MVC или формы asp.net
используйте RouteConfig и WebApiConfig в глобальном.эйсакс как GlobalConfiguration.Настроить(WebApiConfig.Реестр); RouteConfig.RegisterRoutes (RouteTable.Маршруты);
использовать 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 делает испортил его.