wake-up-neo.net

HTTP 404-Seite wurde nicht in der Web-API gefunden, die in gehostet wird IIS 7.5

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

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

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

Am Ende des Tages habe ich alle Verben (verb = "*") für den ExtensionlessUrlHandler-Integrated-4.0-Handler in meiner Web-Konfiguration 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 Thema gestoßen.

84
Kevin Ortman

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

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

Wie in http://www.britishdeveloper.co.uk/2010/06/dont-use-modules-runallmanagedmodulesfo.html beschrieben, sollte die vorstehende Lösung vermieden werden. Verwenden Sie stattdessen diese. Die gleiche Lösung bietet auch Lopsided. Behalten 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>
50
hemant gautam

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ü "Fensterfunktionen ein- oder ausschalten" ein und wählen Sie das erste Ergebnis aus.
  2. Erweitern Sie Internetinformationsdienste: WWW-Dienste: 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.
33
Brandon Gano

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

Zum Beispiel: Ich hatte das gleiche Problem, als ich mein Projekt in mein lokales IIS unter der Default Web Site> SampleWebAPI verschoben habe. Ich glaube, das liegt an der Änderung des URL-Routings wie folgt:

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

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

Zusätzlicher Hinweis: Das Problem wurde durch das Hinzufügen von api als Alias ​​einer Anwendung auf meiner Website weiter verkompliziert, was dazu führte, dass die effektive URL folgendermaßen lautete:

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

Deshalb habe ich die Routing-Regeln in global.asax für die Web-API "DefaultAPI" von api/{controller}/{id} in {controller}/{id} geändert, da ich eine Trennung zwischen meiner Website und der Web-API-MVC-Projekt-Website beibehalten wollte. und der ASP.NET-MVC eine Default von {controller}/{id} nach info/{controller}/{id}.

25
Nicholas Barger

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 wurde umgeleitet und meine globale Datei wurde einfach ignoriert. Ich habe ernsthaft darüber nachgedacht, alles zu beenden, bevor ich diese Antwort gefunden habe. Ich hoffe, dieser Link hilft jemand anderem.


Das Hinzufügen der folgenden Datei zur web.config-Datei funktionierte für mich:

<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 modules -Tag und dann das remove & add -Tag zum modules-Tag hinzugefügt.

13
Lopsided

Ein paar Dinge zu prü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 (falls vorhanden) ausgewählt ist.
  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. Legen Sie die Anwendung in einen eigenen App-Pool.
  6. Stellen Sie sicher, dass das Verzeichnis mindestens Ausführungsberechtigungen "Nur Skripts" hat.
11
Joe Schrag

Ich hatte ein ähnliches Problem. Ich hatte die richtigen Einstellungen in meiner Datei "web.config", aber der Anwendungspool wurde im klassischen Modus und nicht im integrierten Modus ausgeführt.

screen shot

9
Rob Sedgwick

Dieses Problem kann auch aufgrund der folgenden Probleme auftreten 

1.In der Web.Config

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

2.Stellen Sie sicher, dass im Bin-Ordner auf dem Server, auf dem das Web-API bereitgestellt wird, die folgenden Elemente verfügbar sind

  • System.Net.Http

  • System.Net.Http.Formatting

  • System.Web.Http.WebHost

  • System.Web.Http

Diese Assemblys werden standardmäßig nicht im 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 von Visual Studio Publish verfügbar sind, müssen Sie CopyLocal für diese Assemblies auf True setzen

Sadish Kumar.V

6
Sadish Kumar V

Ich bin auch auf dieses Problem gestoßen. Ich habe das Problem gelöst, indem Sie zu Application Pools> Application Pool Name gegangen sind und das .NET Framework von Version 2.0.50727 in Version 4.0.30319 geändert haben.

5
coson

Basierend auf dieser SO Antwort musste ich nur path="*." in path="*" für den hinzugefügten ExtensionlessUrlHandler-Integrated-4.0 in configuration>system.WebServer>handlers in meinem web.config ändern.

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" />
4
Greg

Es gibt ein offizielles Update von Microsoft: http://support.Microsoft.com/kb/980368

Ich empfehle nachdrücklich NICHT die Verwendung von <module runAllManagedModulesForAllRequests = "true"> . Dies führt dazu, dass alle Anforderungen (auch .jpg, .css, .pdf usw.) von allen registrierten HTTP-Modulen verarbeitet werden zwei negative Momente: a) zusätzliche Belastung der Hardwareressourcen; b) mögliche Fehler, da HTTP-Module neue Arten von Inhalten verarbeiten.

3
Roman O

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

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

Ich musste die Option zum Veröffentlichen von Dateien deaktivieren. "Beim Kompilieren vorkompilieren."

2
Pakman

Nach einem Windows Azure-Lernprogramm, in dem ich aufgefordert wurde, meinem Projekt eine Datei "WebRole.cs" hinzuzufügen, erhielt ich 404 Antworten von der Web-API.

Nach dem Entfernen von "WebRole.cs" aus meinem Projekt funktionierten meine Web-API-Aufrufe erneut.

2
Josh Mouch

In meinem Fall bestand das Problem einfach darin, dass ich versuchte, auf die Website unter zuzugreifen

myserver.myintranet.com/mysite

Bei der Website-Bindung für http in IIS wurde jedoch nicht der Hostname in der Bindung angegeben. Es hatte schon einmal geklappt und ich habe keine Ahnung, wie das weggeblasen wurde.

Sobald ich myserver.myintranet.com in den Hostnamen eingetragen habe, war der 404 weg.

Im IIS Manager gehen Sie im Aktionsbereich in Bindings ... und bearbeiten die http-Bindung, um den Hostnamen anzugeben.

2
toddmo

Vergessen Sie nicht, global.asax bereitzustellen 

1
Adem Aygun

Hatte das gleiche Problem, eine 404-Antwort für die Web-API-Controller, wenn vom IIS aus bedient wurde, aber alles funktionierte von VS2010 gut. Keine der oben genannten Lösungen funktionierte für mich. Schließlich stellte ich fest, dass das Problem darin bestand, dass wir WSE 3.0-Unterstützung für die Anwendung hinzugefügt haben und dass die Microsoft.Web.Services3-DLL im Verzeichnis/bin der Anwendung fehlt. Seltsam, aber nach dem Kopieren der DLL begann die Routenzuordnung zu funktionieren.

1
devilcius

Ich hatte auch damit zu kämpfen. Mein genaues Problem war, dass ich einen ASMX-Webdienst hatte. Wenn ich einen Parameter in eine Webmethode eingegeben und getestet habe, würde ich den 404-Wert erhalten. Die jeweilige Methode hat 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. MVC ausgewählt, dann habe ich ein "Hinzufügen"> "Neues Element" vorgenommen, "Visual C #"> "Web" und "Web Service (ASMX)" darunter ausgewählt. Ich habe meinen gesamten Code-Behind-Code kopiert, dann habe ich den Namespace zur Kenntnis genommen, den die neue Datei in meinem neuen Projekt angegeben hat, und dann den gesamten alten Code in die neue Code-Behind-Datei im neuen Projekt eingefügt und den Namespace eingefügt zurück zu dem, was es gewesen war. Dann erstellte ich meine Ordner in meinem Projekt, das ich zuvor mit Visual Studio für "Hinzufügen"> "Neuer Ordner" verwendet hatte, kopierte dann meine Dateien mit Windows Explorer in die Ordner aus meinem anderen Projekt und klickte dann mit der rechten Maustaste auf jeden Ordner in Visual Studio und "Hinzufügen"> "Vorhandenes Element ..." und zog die Elemente in diesen Ordnern in die Visual Studio-Ordner meines neuen Projekts. Ich habe erneut auf alle meine .NET-Assemblys verwiesen, da beide Projekte geöffnet waren, sodass ich vergleichen konnte, welche ich zuvor referenziert hatte (ich hatte eine Menge!). Ich musste mein neues Projekt etwas anders benennen - im Grunde habe ich etwas vergleichbar mit "GeneralWebApp" anstelle von "MyWebApp" zum Beispiel gemacht - also musste ich in meiner gesamten Lösung ein "Alles ersetzen" tun, um diesen Namen zu ersetzen Holen Sie sich den richtigen Namensraum für alle meine Dateien. Dann habe ich ein "Rebuild All" für das Projekt erstellt und dann mit dem "Play" -Button gestartet, den Visual Studio gibt, wenn ich es richtig erstellt habe. Es hat gut funktioniert. Also habe ich es veröffentlicht und alles war gut auf dem Server, auf dem ich es veröffentlicht habe, als ich es von dort aus laufen ließ. Ich habe keine Erklärung, was passiert ist, aber so bin ich durchgekommen. Es ist kein schlechter Test, nur um zu sehen, ob etwas, was Visual Studio macht, es vermasselt hat.

0
vapcguy

Diese Konfiguration in der Datei web.config kann mir dabei helfen:

      <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

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

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

0
Anilkumar Y

Welche Art von HTTP-Anfrage machen Sie? 

Dies ist eine etwas linke Antwort, aber haben Sie 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 eine 404 zurückgibt, wenn ich die falsche ID POST postete. Ich habe festgestellt, dass ich immer die Seite IIS 404 "Datei oder Verzeichnis nicht gefunden" und nicht die HTTP-Antwort von meiner API erhielt. Durch das Entfernen der standardmäßigen 404-Fehlerseite wurde das Problem behoben.

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

0
Oliver Picton

Habe dasselbe Problem mit Web API und .Net Core Web API. Funktionierte in VS 2017 während des Debugging einwandfrei, gab jedoch 404 zurück, wenn diese auf IIS 7.5 veröffentlicht wurde. Die Lösung für mich bestand darin, die Art und Weise zu ändern, wie ich die Site erstellt habe. Anstatt im Stammverzeichnis einer Website zu veröffentlichen (erstellt durch Rechtsklick auf Sites ... Website hinzufügen), musste ich eine Anwendung erstellen (erstellt durch Rechtsklick auf eine Website ... Anwendung hinzufügen) und in diesem Ordner veröffentlichen. Beachten Sie, dass ich für die Core-Version die Einstellung .NET Framework-Version des Anwendungspools auf "Kein verwalteter Code" ändern musste.

0
miked

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

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

0

Ich habe viel Zeit damit verbracht, viele Dinge auszuprobieren, um endlich zu erkennen, dass ich meine Web-App nicht in Sites/Default-Websites, sondern in einer anderen Website, die an einen anderen Port gebunden ist, hinzugefügt hat. Ein Versuch, localhost auf Port 80 auszuführen, würde offensichtlich eine 404 ergeben. 

0
guiomie

Ich hatte kürzlich einen Fehler 404 mit allen meinen Routen/Controllern von Web Api 2 gefunden. Also ging ich auf den eigentlichen Server und versuchte, mithilfe von localhost anstelle des Hostnamens zu browsen, und erhielt "404.7 Not Found - Das Anforderungsfilterungsmodul ist so konfiguriert, dass die Dateierweiterung abgelehnt wird".

Dieser SO Beitrag hilft mir, es zu lösen.

0
santos

Für mich bestand das Problem darin, dass die Stammwebsite für die Verwendung eines .NET 2.0-App-Pools konfiguriert wurde. Meine Anwendung auf dieser Site war .NET 4.5.

Ich habe eine neue Site mit einem .NET 4-App-Pool erstellt und meine Anwendung an den Stamm gestellt - und das hat gut funktioniert.

0
JuniorEbuka

ich tue nichts, füge einfach dieses Tag in web.config hinzu, es funktioniert Dieses Problem wird auf einen der folgenden Punkte hingewiesen

  1. Verwenden Sie Web Api in demselben 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>
0
adnan