Nie znaleziono strony HTTP 404 w interfejsie API sieci Web hostowanej w usługach IIS 7.5

Mam aplikację Web Api. Działa doskonale, gdy testowałem go przy użyciu serwera debugującego VS 2010. Ale teraz wdrożyłem go w IIS 7.5 i otrzymuję błąd HTTP 404 podczas próby uzyskania dostępu do aplikacji.

Oto mój plik 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>

Ja też z tym walczyłem. Na szczęście, Steve Michelotti udokumentowane rozwiązanie, które pracowały dla mnie tutaj .

Pod koniec dnia włączyłem wszystkie czasowniki (verb = "*") do modułu obsługi ExtensionlessUrlHandler-Integrated-4.0 w mojej konfiguracji sieciowej.

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

Inni wskazywali, że włączenie WebDAV powoduje problemy. Na szczęście ja też nie napotkałem tego problemu.

Miał ten sam problem. To ustawienie konfiguracji rozwiązało problem.

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

Jak wyjaśniono w http://www.britishdeveloper.co.uk/2010/06/dont-use-modules-runallmanagedmodulesfo.html , należy unikać powyższego rozwiązania. Użyj tego zamiast tego. To samo rozwiązanie oferuje również Lopsided. Przechowywanie go tutaj, aby użytkownicy mogli uniknąć wdrażania pierwszego działającego rozwiązania.

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

Jeśli usługi IIS są instalowane lub włączane po ASP.NET, należy ręcznie zarejestrować ASP.NET w usługach IIS, aby aplikacja .NET działała.

W systemie Windows 7 i wcześniejszych:

1. Uruchom wiersz polecenia (cmd.exe) jako administrator.
2. Przejdź do odpowiedniej lokalizacji .NET Framework. (np. C: \ Windows \ Microsoft.NET \ Framework64 \ v4.0.30319)
3. Uruchom aspnet_regiis.exe -i

W przypadku systemu Windows 8 i nowszych:

1. W menu Start wpisz „Włącz lub wyłącz funkcje systemu Windows” i wybierz pierwszy wynik.
2. Rozwiń Internet Information Services: World Wide Web Services: Application Development Features i wybierz ASP.NET 4.5 (lub ASP.NET 3.5, jeśli potrzebujesz obsługi projektów w .NET Framework 2.0-3.5).
3. Kliknij OK.

Czy używasz aplikacji interfejsu API sieci Web w katalogu wirtualnym lub aplikacji?

Na przykład: miałem ten sam problem, kiedy przeniosłem projekt do lokalnych usług IIS w domyślnej witrynie sieci Web> SampleWebAPI. Uważam, że wynika to ze zmiany wURL routingu:

Oryginalny: localhost:3092/api/values
przeniesiony: localhost/SampleWebAPI/api/values

Jeśli przeniesiesz projekt interfejsu API sieci Web do własnej witryny internetowej działającej na innym porcie, wydaje się, że działa.

Dodatkowa uwaga: dodatkowo skomplikowałem sprawę, dodając apijako alias aplikacji w mojej witrynie, która spowodowała skutecznośćURL był:

localhost:81/api/api/values - zauważyłem to po przeniesieniu serwisu na własną stronę

Dlatego, ponieważ chciałem zachować oddzielenie między moją witryną internetową a witryną projektu global.asaxWeb API MVC , zmieniłem reguły routingu w interfejsie Web API „DefaultAPI” z api/{controller}/{id}na, {controller}/{id}a ASP.NET MVC Defaultz {controller}/{id}na info/{controller}/{id}.

To jedyna odpowiedź, która mi pomogła ...

Miałem podobny problem ... Wyglądało na to, że bez względu na to, co zrobiłem, nic nie było przekierowywane, a mój plik globalny był po prostu ignorowany. Poważnie rozważałem zakończenie tego wszystkiego, zanim znalazłem tę odpowiedź. Mam nadzieję, że ten link pomoże komuś innemu.

• Przepełnienie stosu - diagnozowanie błędów 404 w usługach IIS 7 i ASP.NET MVC

Dodanie następujących elementów do pliku web.config działało dla mnie:

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

Znacznik system.webServer już tam był, ale dodałem do niego tag modules , a następnie tag remove & add to modules.

Kilka rzeczy do sprawdzenia:

1. Upewnij się, że masz zainstalowaną platformę .NET Framework 4.
2. Upewnij się, że wersja 4 programu .NET Framework jest wybrana dla Twojej witryny internetowej i katalogu wirtualnego (jeśli dotyczy).
3. Upewnij się, że masz zainstalowany MVC lub odpowiednie biblioteki DLL w katalogu bin.
4. Może być konieczne zezwolenie na rozszerzenia usług internetowych ASP.NET 4.0
5. Umieść aplikację w jej własnej puli aplikacji.
6. Upewnij się, że katalog ma przynajmniej uprawnienia do wykonywania „Tylko skrypty”.

Miałem podobny problem. Miałem odpowiednie ustawienia w moim pliku web.config, ale pula aplikacji była uruchamiana w trybie klasycznym, a nie w trybie zintegrowanym

Ten problem może również wystąpić z następujących powodów

W sieci Web.Config

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

2. Upewnij się, że następujące elementy są dostępne w folderze bin na serwerze, na którym wdrożono interfejs API sieci Web

• System.Net.Http

• System.Net.Http.Formatting

• System.Web.Http.WebHost

• System.Web.Http

Te zestawy nie zostaną domyślnie skopiowane do folderu bin, jeśli publikowanie odbywa się za pośrednictwem programu Visual Studio, ponieważ pakiety interfejsu API sieci Web są instalowane za pośrednictwem narzędzia NuGet na komputerze deweloperskim. Jeśli jednak chcesz, aby te pliki były dostępne w ramach publikowania w programie Visual Studio, musisz ustawić CopyLocal na True dla tych zestawów

Sadish Kumar.V

Na podstawie tej SO odpowiedź , po prostu musiał zmienić path="*."się path="*"dla dodany ExtensionlessUrlHandler-Integrated-4.0wconfiguration>system.WebServer>handlers w moimweb.config

Przed:

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

Po:

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

Ja też napotkałem ten problem. Rozwiązałem problem, przechodząc do puli aplikacji> Nazwa puli aplikacji i zmieniłem platformę .NET Framework z wersji 2.0.50727 na 4.0.30319.

Musiałem wyłączyć opcję „Prekompiluj podczas publikowania”.

Istnieje oficjalna poprawka firmy Microsoft: http://support.microsoft.com/kb/980368

Zdecydowanie NIE polecam używania <modułów runAllManagedModulesForAllRequests = "true">. Prowadzi to do tego, że wszystkie żądania (nawet .jpg, .css, .pdf itp.) Będą przetwarzane przez wszystkie zarejestrowane moduły HTTP. Są dwa negatywne momenty: a) dodatkowe obciążenie zasobów sprzętowych; b) potencjalne błędy, ponieważ moduły http będą przetwarzać nowe typy treści.

Zacząłem otrzymywać odpowiedzi 404 z internetowego interfejsu API po wykonaniu samouczka systemu Windows Azure, w którym zalecono mi dodanie pliku „WebRole.cs” do mojego projektu.

Po usunięciu „WebRole.cs” z mojego projektu, moje wywołania interfejsu API sieci Web znów zaczęły działać.

Upewnij się, że pula aplikacji jest w trybie zintegrowanym
i dodaj następujące elementy do pliku web.config:

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

W moim przypadku problem polegał po prostu na tym, że próbowałem uzyskać dostęp do witryny pod adresem

myserver.myintranet.com/mysite

Jednak powiązanie witryny sieci Web dla protokołu http w usługach IIS nie miało nazwy hosta określonej w powiązaniu. To działało wcześniej i nie mam pojęcia, jak to się zdmuchnęło.

Kiedy myserver.myintranet.compodałem nazwę hosta, 404 zniknął.

W Menedżerze IIS przechodzisz do Powiązania ... w okienku akcji, a następnie edytuj powiązanie http, aby określić nazwę hosta.

Nie zapomnij wdrożyć global.asax

Wystąpił ten sam problem, odpowiedź 404 dla kontrolerów interfejsu API sieci Web podczas obsługi z IIS, ale wszystko działało dobrze od VS2010. Żadne z powyższych rozwiązań nie zadziałało. W końcu odkryłem, że problem polegał na tym, że dodaliśmy obsługę WSE 3.0 dla aplikacji i brakowało biblioteki dll Microsoft.Web.Services3 w katalogu aplikacji / bin. Dziwne, ale po skopiowaniu dll zaczęło działać mapowanie tras.

Dla mnie problem polegał na tym, że witryna główna została skonfigurowana do korzystania z puli aplikacji .NET 2.0, a moja aplikacja w tej witrynie to .NET 4.5.

Utworzyłem nową witrynę z pulą aplikacji .NET 4 i umieściłem moją aplikację w katalogu głównym - i to działało dobrze.

Ja też z tym walczyłem. Mój dokładny problem polegał na tym, że miałem usługę sieciową ASMX, która po wprowadzeniu parametru do metody sieciowej i przetestowaniu jej dawała mi 404. Konkretna metoda działała dobrze w przeszłości i nie została zmieniona, tylko ponownie opublikowane. Potem dotarłem tutaj i wypróbowałem wszystkie opublikowane odpowiedzi i nic nie pomogło.

Moje ostateczne rozwiązanie? Wiem, że to drastyczne, ale właśnie stworzyłem nowe rozwiązanie Visual Studio i projekt sieci Web. Wybrałem MVC, a następnie wykonałem „Dodaj”> „Nowy element”, zaznaczono pod nim „Visual C #”> „Sieć” i „Usługa sieci Web (ASMX)”. Skopiowałem cały mój stary kod związany z kodem, następnie zanotowałem przestrzeń nazw, którą dał nowy plik w moim nowym projekcie, a następnie wkleiłem cały mój stary kod do nowego pliku związanego z kodem w nowym projekcie i umieściłem przestrzeń nazw z powrotem do tego, co było.

Następnie utworzyłem foldery w moim projekcie, które miałem przed użyciem programu Visual Studio do „Dodaj”> „Nowy folder”, a następnie skopiowałem z powrotem do folderów z innego projektu za pomocą Eksploratora Windows, a następnie kliknąłem prawym przyciskiem myszy każdy folder w Visual Studio i wykonałem polecenie „Dodaj”> „Istniejący element ...” i pobrałem elementy z tych folderów do folderów programu Visual Studio mojego nowego projektu. Ponownie odwołałem się do wszystkich moich zestawów .NET, mając otwarte oba projekty, więc mogłem porównać, do których odwoływałem się wcześniej (było ich kilka). Musiałem nazwać mój nowy projekt nieco inaczej - w zasadzie zrobiłem coś podobnego do „GeneralWebApp” zamiast na przykład „MyWebApp” - więc musiałem wykonać polecenie „Replace All” w całym rozwiązaniu, aby zastąpić tę nazwę,

Następnie wykonałem „Przebuduj wszystko” w projekcie, a następnie uruchomiłem go przyciskiem „Odtwórz”, który program Visual Studio wyświetla, gdy mam go poprawnie zbudować. Działało dobrze. Więc opublikowałem to i wszystko było w porządku na serwerze, na którym to opublikowałem, kiedy to uruchomiłem. Nie mam wyjaśnienia, co się stało, ale tak właśnie przez to przeszedłem. Nie jest to zły test, aby sprawdzić, czy coś, co robi Visual Studio, zepsuło go.

Jeśli umieścisz tylko folder bin w usługach IIS (po skompilowaniu projektu), ten problem również wystąpi. W takiej sytuacji należy opublikować projekt za pomocą VisualStudio, a następnie umieścić opublikowany folder w usługach IIS.

Jakiego rodzaju żądania HTTP wykonujesz?

To jest nieco lewe pole odpowiedzi, ale czy próbowałeś usunąć domyślną stronę błędu usług IIS dla 404, aby sprawdzić, co faktycznie zwraca Twój interfejs API?

Wystąpił problem polegający na tym, że chciałem, aby metoda kontrolera zwracała kod 404, gdy POSTAŁEM niewłaściwy identyfikator. Zauważyłem, że zawsze otrzymuję stronę IIS 404 „Nie znaleziono pliku lub katalogu” zamiast odpowiedzi HTTP z mojego interfejsu API. Usunięcie domyślnej strony błędu 404 rozwiązało problem.

Inny problem, ale nigdy nie wiesz, że może pomóc;)

Ta część konfiguracji w pliku web.config może mi pomóc: w sekcji 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>      

Niedawno wystąpił błąd 404 Not Found we wszystkich moich trasach / kontrolerach Web Api 2. Więc wszedłem na rzeczywisty serwer i spróbowałem przeglądać używając localhost zamiast nazwy hosta i otrzymałem "404.7 Not Found - moduł filtrowania żądań jest skonfigurowany tak, aby odmawiać rozszerzenia pliku".

Ten wpis SO pomoże mi go rozwiązać.

Problem został rozwiązany dla mnie, kiedy włączam pole wyboru dla UrlRoutingModule-4.0:

Menedżer IIS> Moduły> wybierz UrlRoutingModule-4.0> Edytuj moduł> zaznacz pole wyboru „Wywołaj tylko dla żądań do aplikacji ASP.NET lub zarządzanych programów obsługi”.

Miałem ten sam problem: na nowo zainstalowanej maszynie z Visual Studio 2013 projekt interfejsu API sieci Web działał pod IISExpress, ale nie pod lokalnymi IIS. Próbowałem wszystkiego, co mogłem znaleźć, ale ostatecznie problem nie był konieczny z Web API, ale z MVC: nawet gdy był zainstalowany, żaden projekt MVC nie działał.

Pomogło mi odinstalowanie usług IIS (z DODAJ / USUŃ funkcje systemu Windows), a następnie ponowne ich zainstalowanie i uruchomienie aspnet_regiis -i. Może to pomoże komuś innemu.

Spędziłem dużo czasu próbując wielu rzeczy, aby w końcu zdać sobie sprawę, że dodawałem moją aplikację internetową nie w Witrynach / Domyślnych Witrynach internetowych, ale w innej witrynie połączonej z innym portem. Oczywiście wypróbowanie localhost na porcie 80 dałoby 404.

nic nie robię, po prostu dodaj ten tag w web.config, jego działanie w tym problemie pojawia się jeden z następujących punktów

1. Użyj interfejsu API sieci Web w tym samym projekcie przy użyciu formularzy MVC lub asp.net

2. Użyj RouteConfig i WebApiConfig w Global.asax jako GlobalConfiguration.Configure (WebApiConfig.Register); RouteConfig.RegisterRoutes (RouteTable.Routes);

3. Użyj RouteConfig do 2 celów, formularzy asp.net przy użyciu z przyjaznym adresem URL i routingiem MVC dla routingu MVC

po prostu używamy tego tagu w web.config, to zadziała.

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

Napotkałem ten sam problem z interfejsem API sieci Web i interfejsem API sieci Web .Net Core. Działał dobrze w VS 2017 podczas debugowania, ale zwrócił 404 po opublikowaniu w usługach IIS 7.5. Rozwiązaniem dla mnie była zmiana sposobu tworzenia strony. Zamiast publikować w katalogu głównym witryny sieci Web (utworzonej przez kliknięcie prawym przyciskiem Witryny ... Dodaj witrynę sieci Web), musiałem utworzyć aplikację (utworzoną przez kliknięcie witryny sieci Web prawym przyciskiem myszy ... Dodaj aplikację) i opublikować w tym folderze. Zauważ, że w przypadku wersji Core musiałem zmienić ustawienie wersji puli aplikacji .NET Framework na „Brak kodu zarządzanego”.

Dla mnie rozwiązaniem było usunięcie następujących wierszy z mojego pliku 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>

Zauważyłem, że VS dodał je automatycznie, nie wiem dlaczego

Wypróbuj ten webconfg .. zamień plik „NewsApi.dll” na swój główny plik 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>