it-swarm.com.de

Die ASP.NET-Web-API-Anwendung gibt 404 bei der Bereitstellung an IIS 7

Ich habe eine ASP.NET-Web-API, die unter "IIS Express" mit localhost: 1783 gut funktioniert

Settings in VS

Wenn ich jedoch den "Use IIS Express" nicht durchquere und dann "Create Virtual Directory" drücke ...

New settings

Ich bekomme nur 404 Fehler: The 404 error

Irgendwelche Ideen, was ist falsch? Vielen Dank!

51
Cotten

Während die markierte Antwort funktioniert, müssen Sie der webconfig wirklich nur Folgendes hinzufügen:

    <handlers>
      <!-- Your other remove tags-->
      <remove name="UrlRoutingModule-4.0"/>
      <!-- Your other add tags-->
      <add name="UrlRoutingModule-4.0" path="*" verb="*" type="System.Web.Routing.UrlRoutingModule" preCondition=""/>
    </handlers>

Beachten Sie, dass keine davon eine bestimmte Reihenfolge hat, obwohl Sie Ihre Entfernungen vor Ihren Hinzufügungen haben möchten.

Der Grund dafür, dass wir am Ende eine 404 erhalten, ist, dass das URL-Routing-Modul nur die Wurzel der Website in IIS einsetzt. Durch das Hinzufügen des Moduls zur Konfiguration dieser Anwendung haben wir das Modul, das unter dem Pfad dieser Anwendung (Ihrem Unterverzeichnispfad) ausgeführt wird, und das Routing-Modul setzt ein.

38
DavidAndroidDev

Für mich musste ich neben runAllManagedModulesForAllRequests="true" auch das "path" Attribut unten bearbeiten. Zuvor war mein Pfadattribut "*.", was bedeutet, dass es nur auf URLs ausgeführt wurde, die ein Punkt Enthalten. Die URLs meiner Anwendung enthalten jedoch keinen Punkt. Wenn ich den Pfad zu "*" gewechselt habe, hat es geklappt ..__ Folgendes habe ich jetzt:

  <system.webServer>
      <validation validateIntegratedModeConfiguration="false" />
      <modules runAllManagedModulesForAllRequests="true">
      <remove name="WebDAVModule"/>
      </modules>

      <handlers>
          <remove name="WebDAV" />
          <remove name="ExtensionlessUrlHandler-ISAPI-4.0_32bit" />
          <remove name="ExtensionlessUrlHandler-ISAPI-4.0_64bit" />
          <remove name="ExtensionlessUrlHandler-Integrated-4.0" />
          <add name="ExtensionlessUrlHandler-ISAPI-4.0_32bit" path="*" verb="*" modules="IsapiModule" scriptProcessor="%windir%\Microsoft.NET\Framework\v4.0.30319\aspnet_isapi.dll" preCondition="classicMode,runtimeVersionv4.0,bitness32" responseBufferLimit="0" />
          <add name="ExtensionlessUrlHandler-ISAPI-4.0_64bit" path="*" verb="*" modules="IsapiModule" scriptProcessor="%windir%\Microsoft.NET\Framework64\v4.0.30319\aspnet_isapi.dll" preCondition="classicMode,runtimeVersionv4.0,bitness64" responseBufferLimit="0" />
          <add name="ExtensionlessUrlHandler-Integrated-4.0" path="*" verb="*" type="System.Web.Handlers.TransferRequestHandler" preCondition="integratedMode,runtimeVersionv4.0" />
      </handlers>
  </system.webServer>
14

Möglicherweise müssen Sie Hotfix KB980368 installieren. 

Dieser Artikel beschreibt ein Update, mit dem bestimmte Handler für Internetinformationsdienste (IIS) 7.0 oder IIS 7.5 Anforderungen behandeln können, deren URLs nicht mit einem Zeitraum enden. Diese Handler werden speziell "" zugeordnet. Anforderungspfade. Derzeit ist ein Handler einem "" zugeordnet. Der Anforderungspfad behandelt nur Anforderungen, deren URLs mit einem Punkt enden. Beispielsweise behandelt der Handler nur Anforderungen, deren URLs der folgenden URL ähneln:

http://www.example.com/ExampleSite/ExampleFile .

Nachdem Sie dieses Update angewendet haben, werden Handler, die einem "*" zugeordnet sind. Der Anforderungspfad kann Anforderungen verarbeiten, deren URLs mit einem Punkt enden, und Anforderungen, deren URLs nicht mit einem Punkt enden. Zum Beispiel kann der Handler jetzt Anforderungen bearbeiten, die den folgenden URLs ähneln:

http://www.example.com/ExampleSite/ExampleFile

http://www.example.com/ExampleSite/ExampleFile .

Nachdem dieser Patch angewendet wurde, können ASP.NET 4-Anwendungen Anforderungen nach erweiterungslosen URLs verarbeiten. Daher werden verwaltete HttpModules ausgeführt, die vor der Ausführung des Handlers ausgeführt werden. In einigen Fällen können die HttpModules Fehler für URLs ohne Erweiterung zurückgeben. Beispielsweise kann ein HttpModule, das so geschrieben wurde, dass nur ASPX-Anforderungen erwartet werden, jetzt Fehler zurückgeben, wenn versucht wird, auf die HttpContext.Session-Eigenschaft zuzugreifen.

10
Tony

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

8
Sadish Kumar V

Einige Leute sagen, dass runAllManagedModulesForAllRequests = "true" Leistungsprobleme und MVC-Routing-Probleme haben wird.

http://www.britishdeveloper.co.uk/2010/06/dont-use-modules-runallmanagemodulesfo.html

http://bartwullems.blogspot.com/2012/06/optimize-performance-of-your-web.html

2
Jeff

Für mich war dieses Problem ein wenig anders als bei anderen Antworten, da ich nur 404s für OPTIONS erhielt. Ich hatte jedoch bereits OPTIONS in meinen Integrated Extensionless URL Handler-Optionen angegeben. Sehr verwirrend.

  1. Wie andere bereits festgestellt haben, ist runAllManagedModulesForAllRequests = "true" in Der Modulknoten ist eine einfache Möglichkeit, die meisten Probleme mit der Web-API 404 zu beheben - obwohl ich die Antwort von @DavidAndroidDev vorziehen möchte, die weniger aufdringlich ist. Aber in meinem Fall gab es noch etwas mehr.
  2. Leider hatte ich dieses Set in IIS unter Anforderungsfilterung auf der Site:

 OPTIONS Issue with Request Filtering

Durch Hinzufügen des folgenden security-Knotens zur web.config war es erforderlich, den gesamten für den Kontext eingeschlossenen system.webserver auszuschalten:

  <system.webServer>
    <modules runAllManagedModulesForAllRequests="true">
      <remove name="WebDAVModule" />
    </modules>
    <handlers>
      <remove name="ExtensionlessUrlHandler-Integrated-4.0" />
      <remove name="OPTIONSVerbHandler" />
      <remove name="TRACEVerbHandler" />
      <remove name="WebDAV" />
      <add name="ExtensionlessUrlHandler-Integrated-4.0" path="*." verb="*" type="System.Web.Handlers.TransferRequestHandler" preCondition="integratedMode,runtimeVersionv4.0" />
    </handlers>
    <security>
      <requestFiltering>
        <verbs>
          <remove verb="OPTIONS" />
        </verbs>
      </requestFiltering>
    </security>
  </system.webServer>

Obwohl dies nicht die perfekte Antwort auf diese Frage ist, ist es das erste Ergebnis für "IIS OPTIONS 404" bei Google. Ich hoffe, das hilft jemandem. kostete mich heute eine Stunde. 

0

Ich habe auf meinen Websites einen Fehler 404 erhalten, der NICHT IIS Express (unter Verwendung von Local IIS) verwendet, während eine Anwendung ausgeführt wurde, die WAS IIS Express verwendet hat. Wenn ich den Browser schließen würde, der zum Ausführen von IIS Express verwendet wurde, würde der 404 wegfallen. Für mich hatte ich mein IIS Express-Projekt in Local IIS Dienste aufgerufen, also habe ich das IIS Express-Projekt in Local IIS und konvertiert dann hat alles geklappt. Es scheint, dass Sie nicht gleichzeitig eine Nicht-IIS Express- und eine Local IIS Website ausführen können.

0
deadlydog

Ich habe dieses Problem seit einigen Tagen bekämpft und alle möglichen Vorschläge gemacht. Mein Entwicklungscomputer funktionierte einwandfrei, aber der neue Computer, für den ich implementiert wurde, gab mir den Fehler 404. 

In IIS Manager habe ich die Handlerzuordnungen auf beiden Maschinen verglichen, um zu erkennen, dass viele Handler fehlten. Es stellt sich heraus, dass ASP.Net 5 nicht auf dem Computer installiert wurde. 

0
yannb

Wenn Sie Visual Studio 2012 verwenden, laden Sie das Update 2 herunter, das Microsoft kürzlich veröffentlicht hat (Stand 4/2013).

Visual Studio 2012 Update 2

Dieses Update enthält einige Fehlerbehebungen, die sich auf das Problem beziehen.

0
mitaka

Ich hatte das gleiche Problem. Nach vielen Forschungs- und Entwicklungsarbeiten habe ich das Problem gefunden.

aber solange Ihre Konfiguration abgeschlossen ist, bedeutet dies, dass aspnet 64-Bit und IIS gut Das einzige Problem, das ich sah, ist der Pfad "Web-API, der den lokalen Direktionspfad verwendet", so dass Sie dies vermeiden müssen. von like this .. ~ ../../../ api/products/

vielen Dank für das Posten des Problems. Ich leanred viel abt iis und andere Einstellung in der Konfigurationsdatei.

0
SRIRAM