HTTP 404-Seite in Web-API in IIS 7.5 nicht gefunden

Ich habe eine Web-API-Anwendung. Es funktioniert einwandfrei, als ich es mit dem VS 2010 Debugging Dev Server getestet habe. Aber ich habe es jetzt in IIS 7.5 bereitgestellt und erhalte einen HTTP 404-Fehler, wenn ich versuche, auf die Anwendung zuzugreifen.

Hier ist meine 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>

Ich hatte auch damit zu kämpfen. Glücklicherweise dokumentiert Steve Michelotti eine Lösung , die für mich gearbeitet hier .

Am Ende des Tages habe ich alle Verben (verb = "*") für den ExtensionlessUrlHandler-Integrated-4.0-Handler in meiner Webkonfiguration aktiviert.

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

Andere haben darauf hingewiesen, dass die Aktivierung von WebDAV Probleme verursacht. Glücklicherweise bin ich auch nicht auf dieses Problem gestoßen.

Hatte das gleiche Problem. Diese Konfigurationseinstellung hat das Problem behoben.

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

Wie unter http://www.britishdeveloper.co.uk/2010/06/dont-use-modules-runallmanagedmodulesfo.html erläutert, sollte die obige Lösung vermieden werden. Verwenden Sie dies stattdessen. Die gleiche Lösung bietet auch Lopsided. Lassen Sie es hier, damit Benutzer die Implementierung der ersten funktionierenden Lösung vermeiden können.

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

Wenn IIS nach ASP.NET installiert oder aktiviert ist, müssen Sie ASP.NET manuell bei IIS registrieren, damit Ihre .NET-Anwendung funktioniert.

Für Windows 7 und früher:

1. Führen Sie die Eingabeaufforderung (cmd.exe) als Administrator aus.
2. Navigieren Sie zum entsprechenden .NET Framework-Speicherort. (z. B. C: \ Windows \ Microsoft.NET \ Framework64 \ v4.0.30319)
3. Führen Sie aspnet_regiis.exe -i aus

Für Windows 8 und höher:

1. Geben Sie im Startmenü "Windows-Funktionen ein- oder ausschalten" ein und wählen Sie das erste Ergebnis aus.
2. Erweitern Sie Internetinformationsdienste: World Wide Web Services: Anwendungsentwicklungsfunktionen und wählen Sie ASP.NET 4.5 (oder ASP.NET 3.5, wenn Sie Projekte unter .NET Framework 2.0-3.5 unterstützen müssen).
3. OK klicken.

Führen Sie die Web-API-App in einem virtuellen Verzeichnis oder einer Anwendung aus?

Beispiel: Ich hatte das gleiche Problem, als ich mein Projekt auf meinen lokalen IIS unter der Standardwebsite> SampleWebAPI verschoben habe. Ich glaube, das liegt an der Änderung des URLRoutings wie folgt:

Original: localhost:3092/api/values
Umgezogen: localhost/SampleWebAPI/api/values

Wenn Sie das Web-API-Projekt auf eine eigene Website verschieben, die auf einem anderen Port ausgeführt wird, scheint es zu funktionieren.

Zusätzlicher Hinweis: Ich habe das Problem weiter verkompliziert, indem ich apials Alias ​​einer Anwendung auf meiner Website Folgendes hinzugefügt habe, wodurch Folgendes wirksam wurde URL:

localhost:81/api/api/values - bemerkte dies, nachdem die Website auf eine eigene Website verschoben wurde

Da ich eine Trennung zwischen meiner Website und der Web-API-MVC-Projektwebsite beibehalten wollte, habe ich die Routing-Regeln global.asaxfür die Web-API "DefaultAPI" von api/{controller}/{id}bis {controller}/{id}und für die ASP.NET MVC Defaultvon {controller}/{id}bis geändert info/{controller}/{id}.

Dies ist die einzige Antwort, die für mich funktioniert hat ...

Ich hatte ein ähnliches Problem ... Es schien, als würde, egal was ich tat, nichts umgeleitet und meine globale Datei wurde einfach ignoriert. Ich dachte ernsthaft darüber nach, alles zu beenden, bevor ich diese Antwort fand. Ich hoffe dieser Link hilft jemand anderem.

• Stapelüberlauf - Diagnose von 404-Fehlern unter IIS 7 und ASP.NET MVC

Das Hinzufügen von Folgendem zur Datei web.config hat bei mir funktioniert:

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

Das system.webServer- Tag war natürlich schon da, aber ich habe das Module- Tag hinzugefügt und dann das Remove & Add- Tag zum Module-Tag.

Ein paar Dinge zu überprüfen:

1. Stellen Sie sicher, dass Sie .NET Framework 4 installiert haben.
2. Stellen Sie sicher, dass Version 4 von .NET Framework für Ihre Website und Ihr virtuelles Verzeichnis ausgewählt ist (falls zutreffend).
3. Stellen Sie sicher, dass Sie MVC installiert haben oder die entsprechenden DLLs in Ihrem bin-Verzeichnis haben.
4. Möglicherweise müssen ASP.NET 4.0-Webdiensterweiterungen zugelassen werden
5. Stellen Sie die Anwendung in einen eigenen App-Pool.
6. Stellen Sie sicher, dass das Verzeichnis mindestens über Ausführungsberechtigungen "Nur Skripte" verfügt.

Ich hatte ein ähnliches Problem. Ich hatte die richtigen Einstellungen in meiner Datei web.config, führte den Anwendungspool jedoch im klassischen Modus und nicht im integrierten Modus aus

Dieses Problem kann auch aus folgenden Gründen auftreten

1.In der Web.Config

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

2.Stellen Sie sicher, dass im Ordner bin auf dem Server, auf dem die Web-API bereitgestellt wird, Folgendes verfügbar ist

• System.Net.Http

• System.Net.Http.Formatting

• System.Web.Http.WebHost

• System.Web.Http

Diese Assemblys werden standardmäßig nicht in den Ordner bin kopiert, wenn die Veröffentlichung über Visual Studio erfolgt, da die Web-API-Pakete über Nuget auf dem Entwicklungscomputer installiert werden. Wenn Sie jedoch möchten, dass diese Dateien als Teil der Visual Studio-Veröffentlichung verfügbar sind, müssen Sie CopyLocal für diese Assemblys auf True setzen

Sadish Kumar.V

Auf der Grundlage dieser SO Antwort , die ich ändern habe gerade path="*."zu path="*"für die hinzugefügte ExtensionlessUrlHandler-Integrated-4.0in configuration>system.WebServer>handlersmeinemweb.config

Vor:

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

Nach dem:

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

Ich bin auch auf dieses Problem gestoßen. Ich habe das Problem gelöst, indem ich zu Anwendungspools> Name des Anwendungspools gegangen bin und .NET Framework von Version 2.0.50727 auf Version 4.0.30319 geändert habe.

Ich musste die Dateiveröffentlichungsoption "Während der Veröffentlichung vorkompilieren" deaktivieren.

Es gibt einen offiziellen Fix von Microsoft: http://support.microsoft.com/kb/980368

Ich empfehle dringend, <modules runAllManagedModulesForAllRequests = "true"> zu verwenden. Dies führt dazu, dass alle Anforderungen (auch JPG, CSS, PDF usw.) von allen registrierten HTTP-Modulen verarbeitet werden. Es gibt zwei negative Momente: a) zusätzliche Belastung der Hardwareressourcen; b) mögliche Fehler, da http-Module neue Arten von Inhalten verarbeiten.

Ich habe 404 Antworten von der Web-API erhalten, nachdem ich einem Windows Azure-Lernprogramm gefolgt war, in dem ich aufgefordert wurde, meinem Projekt eine Datei "WebRole.cs" hinzuzufügen.

Nachdem ich "WebRole.cs" aus meinem Projekt entfernt hatte, funktionierten meine Web-API-Aufrufe wieder.

Stellen Sie sicher, dass sich der Anwendungspool im integrierten Modus befindet,
und fügen Sie der Datei web.config Folgendes hinzu:

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

In meinem Fall war das Problem einfach, dass ich versuchte, auf die Site unter zuzugreifen

myserver.myintranet.com/mysite

Für die Website-Bindung für http in IIS wurde jedoch nicht der in der Bindung angegebene Hostname angegeben. Es hatte schon früher funktioniert und ich habe keine Ahnung, wie das weggeblasen wurde.

Nachdem ich myserver.myintranet.comden Hostnamen eingegeben hatte, war der 404 verschwunden.

In IIS Manager gehen Sie im Aktionsbereich zu Bindungen ... und bearbeiten dann die http-Bindung, um den Hostnamen anzugeben.

Vergessen Sie nicht, global.asax bereitzustellen

Hatte das gleiche Problem, eine 404-Antwort für die Web-API-Controller, wenn sie vom IIS bereitgestellt wurden, aber ab VS2010 funktionierte alles einwandfrei. Keine der oben genannten Lösungen hat bei mir funktioniert. Schließlich stellte ich fest, dass das Problem darin bestand, dass wir die WSE 3.0-Unterstützung für die Anwendung hinzugefügt haben und die DLL Microsoft.Web.Services3 im Verzeichnis / bin der Anwendung fehlte. Seltsam, aber nach dem Kopieren der DLL begann die Routenzuordnung zu funktionieren.

Für mich war das Problem, dass die Root-Site für die Verwendung eines .NET 2.0-App-Pools konfiguriert wurde und meine Anwendung auf dieser Site .NET 4.5 war.

Ich habe eine neue Site mit einem .NET 4-App-Pool erstellt und meine Anwendung im Stammverzeichnis platziert - und das hat gut funktioniert.

Ich hatte auch damit zu kämpfen. Mein genaues Problem war, dass ich einen ASMX-Webdienst hatte, der mir, wenn ich einen Parameter in eine Webmethode eingab und ihn testete, die 404 gab. Die bestimmte Methode hatte in der Vergangenheit gut funktioniert und war nicht geändert worden. nur neu veröffentlicht. Dann bin ich hierher gekommen und habe alle geposteten Antworten ausprobiert und nichts hat geholfen.

Meine ultimative Lösung? Ich weiß, dass dies drastisch ist, aber ich habe gerade eine neue Visual Studio-Lösung und ein neues Webprojekt erstellt. Ausgewählte MVC, dann habe ich ein "Hinzufügen"> "Neues Element" gemacht, darunter "Visual C #"> "Web" und "Web Service (ASMX)" ausgewählt. Ich habe meinen gesamten alten CodeBehind-Code kopiert, dann den Namespace notiert, den die neue Datei in meinem neuen Projekt erhalten hat, dann meinen gesamten alten Code in die neue CodeBehind-Datei im neuen Projekt eingefügt und den Namespace eingefügt zurück zu dem, was es gewesen war.

Dann habe ich meine Ordner in meinem Projekt erstellt, die ich vor der Verwendung von Visual Studio für "Hinzufügen"> "Neuer Ordner" hatte, dann mit Windows Explorer in meine Dateien zurück in die Ordner meines anderen Projekts kopiert und dann mit der rechten Maustaste auf jeden Ordner geklickt Visual Studio und hat "Hinzufügen"> "Vorhandenes Element ..." ausgeführt und die Elemente in diesen Ordnern in die Visual Studio-Ordner meines neuen Projekts gezogen. Ich habe erneut auf alle meine .NET-Assemblys verwiesen, wobei beide Projekte geöffnet waren, damit ich vergleichen konnte, auf welche ich zuvor verwiesen hatte (es gab mehrere). Ich musste mein neues Projekt etwas anders benennen - im Grunde habe ich etwas getan, das mit "GeneralWebApp" anstelle von "MyWebApp" vergleichbar war - also musste ich in meiner gesamten Lösung "Alle ersetzen" ausführen, um diesen Namen zu ersetzen.

Dann habe ich ein "Alle neu erstellen" für das Projekt durchgeführt und es dann mit der Schaltfläche "Abspielen" gestartet, die Visual Studio gibt, wenn ich es richtig erstellt habe. Es hat gut funktioniert. Also habe ich es veröffentlicht und alles war in Ordnung auf dem Server, auf dem ich es veröffentlicht habe, als ich es von dort aus ausgeführt habe. Ich habe keine Erklärung, was passiert ist, aber so bin ich durchgekommen. Es ist kein schlechter Test, nur um zu sehen, ob etwas, das Visual Studio tut, es vermasselt hat.

Welche Art von HTTP-Anfrage stellen Sie?

Dies ist eine Antwort im linken Feld. Haben Sie jedoch versucht, die IIS-Standardfehlerseite für 404 zu entfernen, um zu überprüfen, was Ihre API tatsächlich zurückgibt?

Ich hatte ein Problem, bei dem ich wollte, dass eine Controller-Methode einen 404 zurückgibt, wenn ich die falsche ID darauf poste. Ich habe festgestellt, dass ich immer die IIS 404-Seite "Datei oder Verzeichnis nicht gefunden" anstelle der HTTP-Antwort von meiner API erhalten habe. Durch Entfernen der Standard-404-Fehlerseite wurde das Problem behoben.

Anderes Problem, aber Sie wissen nie, dass es helfen kann;)

Diese Konfiguration in der Datei web.config kann mir dabei helfen: im Abschnitt 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>      

Ich hatte vor kurzem einen 404 nicht gefundenen Fehler mit allen meinen Web Api 2 Routen / Controllern. Also ging ich auf den eigentlichen Server und versuchte, mit localhost anstelle des Hostnamens zu surfen und bekam "404.7 Not Found - Das Anforderungsfiltermodul ist so konfiguriert, dass die Dateierweiterung verweigert wird".

Dieser SO-Beitrag hilft mir bei der Lösung.

Es wurde für mich behoben, als ich das Kontrollkästchen für UrlRoutingModule-4.0 aktivierte:

IIS-Manager> Module> Wählen Sie UrlRoutingModule-4.0> Modul bearbeiten> Aktivieren Sie das Kontrollkästchen "Nur für Anforderungen an ASP.NET-Anwendungen oder verwaltete Handler aufrufen".

Ich hatte das gleiche Problem: Auf einem neu installierten Computer mit Visual Studio 2013 arbeitete das Web-API-Projekt unter IISExpress, jedoch nicht unter lokalem IIS. Ich habe alles versucht, was ich finden konnte, aber am Ende war das Problem mit der Web-API nicht notwendig, sondern mit MVC: Selbst wenn es installiert war, wurde kein MVC-Projekt ausgeführt.

Für mich funktionierte es, IIS (von ADD / REMOVE Windows Features) zu deinstallieren, dann neu zu installieren und dann aspnet_regiis -i auszuführen. Vielleicht hilft das jemand anderem.

Ich habe viel Zeit damit verbracht, viele Dinge auszuprobieren, um endlich zu erkennen, dass ich meine Web-App nicht auf Websites / Standard-Websites, sondern auf einer anderen Website hinzugefügt habe, die an einen anderen Port gebunden ist. Offensichtlich würde ein Versuch von localhost auf Port 80 einen 404 ergeben.

Ich mache nichts, füge einfach dieses Tag in web.config hinzu, es funktioniert dieses Problem, wenn einer der folgenden Punkte auftaucht

1. Verwenden Sie Web Api im selben Projekt mit MVC- oder asp.net-Formularen

2. Verwenden Sie RouteConfig und WebApiConfig in Global.asax als GlobalConfiguration.Configure (WebApiConfig.Register). RouteConfig.RegisterRoutes (RouteTable.Routes);

3. Verwenden Sie RouteConfig für zwei Zwecke, asp.net-Formulare mit Friendlyurl- und MVC-Routing für MVC-Routing

Wir verwenden dieses Tag nur in web.config, es wird funktionieren.

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

Ist auf dasselbe Problem mit der Web-API und der .Net Core-Web-API gestoßen. Funktionierte in VS 2017 beim Debuggen einwandfrei, gab jedoch bei Veröffentlichung in IIS 7.5 404 zurück. Die Lösung für mich bestand darin, die Art und Weise zu ändern, in der ich die Site erstellt habe. Anstatt im Stammverzeichnis einer Website zu veröffentlichen (erstellt durch Klicken mit der rechten Maustaste auf Websites ... Website hinzufügen), musste ich eine Anwendung erstellen (erstellt durch Klicken mit der rechten Maustaste auf eine Website ... Anwendung hinzufügen) und in diesem Ordner veröffentlichen. Beachten Sie, dass ich für die Core-Version die .NET Framework-Versionseinstellung des Anwendungspools in "Kein verwalteter Code" ändern musste.

Für mich bestand die Lösung darin , die folgenden Zeilen aus meiner Datei web.config zu entfernen:

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

Ich bemerkte, dass VS sie automatisch hinzugefügt hatte, nicht sicher warum

Versuchen Sie diese Webconfg .. ersetzen Sie "NewsApi.dll" durch Ihre Haupt-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>

Wenn Sie nur den Ordner bin in IIS ablegen (nach dem Erstellen des Projekts), tritt auch dieses Problem auf. In dieser Situation sollten Sie veröffentlichen das Projekt mit Visual Studio, dann legen Sie die veröffentlichten Ordner in IIS.