ASP.NET MVC unter IIS 7.5

Ich verwende Windows 7 Ultimate (64 Bit) mit Visual Studio 2010 RC. Ich habe kürzlich beschlossen, dass VS meine Apps auf IIS ausführt / debuggt und nicht auf dem mitgelieferten Entwicklungsserver.

Jedes Mal, wenn ich versuche, eine MVC-App auszuführen, wird folgende Fehlermeldung angezeigt:

HTTP-Fehler 403.14 - Verboten Der Webserver ist so konfiguriert, dass der Inhalt dieses Verzeichnisses nicht aufgelistet wird. Detailliert

Fehlerinformationen

Modul DirectoryListingModule

Benachrichtigung ExecuteRequestHandler

Handler StaticFile-Fehler

Code 0x00000000 Angefordert

URL http: // localhost: 80 / mySite /

Physischer Pfad C: \ myProject \ mySite \

Anmeldemethode Anonyme Anmeldung

Benutzer anonym

Ich habe eine default.aspxDatei in das Verzeichnis gestellt und die folgende Fehlermeldung erhalten:

HTTP-Fehler 500.21 - Interner Server-Fehlerbehandler "PageHandlerFactory-Integrated" hat ein fehlerhaftes Modul "ManagedPipelineHandler" in seiner Modulliste

Gibt es noch andere Schritte, die ich vergessen habe, um dies zum Laufen zu bringen?

Hinweise: Ich habe IIS 7.5 nach der Installation von VS 2010 RC installiert. Ich habe die integrierte Schaltfläche "Virtuelles Verzeichnis erstellen" unter der Registerkarte "Web" in den "Eigenschaften" des MVC-Projekts in Visual Studio 2010 verwendet. Ich habe sichergestellt, dass die Anwendung den ASP.NET 4-App-Pool verwendet.

Unten sind die installierten Funktionen von IIS aufgeführt.

ASP.NET 4 wurde nicht in IIS registriert. Musste den folgenden Befehl in der Kommandozeile ausführen / ausführen

32-Bit (x86) Windows

% windir% \ Microsoft.NET \ Framework \ v4.0.30319 \ aspnet_regiis.exe -ir

64-Bit (x64) Windows

% windir% \ Microsoft.NET \ Framework64 \ v4.0.30319 \ aspnet_regiis.exe -ir

Anmerkung aus David Murdochs Kommentar:

Dass sich die .net-Version geändert hat, seit diese Antwort veröffentlicht wurde. Überprüfen Sie, welche Version des Frameworks sich im Verzeichnis% windir% \ Microsoft.NET \ Framework64 befindet, und ändern Sie den Befehl entsprechend, bevor Sie ihn ausführen (derzeit v4.0.30319).

Eine weitere Sache, die Sie sicherstellen müssen, ist das folgende Set in Ihrer web.config:

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

Stellen Sie sicher, dass in Ihrer web.config Folgendes festgelegt ist:

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

Bessere Lösung:

Obwohl die obige Lösung absolut einwandfrei funktioniert , kann sie andere Probleme verursachen, da alle registrierten HTTP-Module bei jeder Anforderung ausgeführt werden (auch bei jeder Anforderung von .jpg .gif .css .html .pdf usw.) und offensichtlich Ressourcenverschwendung ist. Stattdessen

<system.webServer>
<modules>
  <remove name="UrlRoutingModule-4.0"/>
  <add name="UrlRoutingModule-4.0" type="System.Web.Routing.UrlRoutingModule, System.Web, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" preCondition="" />
</modules>
</system.webServer>

Stellen Sie sicher, dass das Attribut preCondition leer ist. Dies bedeutet, dass es bei allen Anforderungen ausgeführt wird. [Lesen Sie mehr] ( http://www.britishdeveloper.co.uk/2010/06/dont-use-modules-runallmanagedmodulesfo.html , "Read original post")

Ein weiterer Grund, warum jemand diesen Fehler erhalten könnte, ist, dass sich die Datei Global.asax nicht mehr im Stammordner befindet.

Ich habe auch diesen Fehler erhalten und festgestellt, dass "HTTP-Umleitung" in Windows Server nicht aktiviert war. Dieser Blog-Beitrag weist auch darauf hin: http://blogs.msdn.com/b/rjacobs/archive/2010/06/30/system-web-routing-routetable-not-working-with-iis.aspx

Gütiger Gott. Ich habe alle oben genannten Dinge ausprobiert (aber meine Einstellungen waren identisch). NOCH EINE ANDERE LÖSUNG, wenn Sie Probleme haben:

http://support.microsoft.com/kb/980368

Versuchen Sie, diese KB für Ihr System zu installieren. Wenn Sie 404s sehen, könnte dies daran liegen, dass Sie dieses Update nicht haben - und das Isapi-Modul wird einfach nicht gefunden und es gibt nicht viel, was Sie dagegen tun können!

Sie können AppPool auch in den integrierten Modus schalten. Vielen Dank an Michael Bianchi ( https://stackoverflow.com/a/7956546/1143515 ), das möchte ich nur unterstreichen.

Für mich auf einer Azure Server 2012 R2 IIS 8.5-VM mit einer Asp.Net MVC 5-App (bin Deployed MVC 5) musste ich an einer Eingabeaufforderung mit erhöhtem cmd Folgendes tun, obwohl ich 4.5 bereits installiert hatte:

dism /online /enable-feature /featurename:IIS-ASPNET45

Quelle: http://support.microsoft.com/kb/2736284

Ich habe auch Brute Force alle IIS-Funktionen mit der folgenden PowerShell installiert:

import-module servermanager
add-windowsfeature web-server -includeallsubfeature

Quelle: http://www.iis.net/learn/install/installing-iis-85/installing-iis-85-on-windows-server-2012-r2

Jetzt funktioniert meine App.

Wir hatten eine MVC-Anwendung auf einen neuen Server verschoben. .NET 4 und MVC 3 wurden installiert, aber wir haben immer noch "Fehler 403.14". In diesem Fall bedeutete dies, dass IIS nicht verstand, dass es sich um eine MVC-Anwendung handelte, sondern nach der Standardseite suchte.

Die Lösung war einfach: Die HTTP-Umleitung wurde nicht auf dem Server installiert.

Server Manager - Rollen - Webserver (IIS) - Rollendienste - HTTP-Umleitung: Nicht installiert. Installiert, Problem gelöst.

Auch wenn Ihre App vorkompiliert ist, sollten Sie haben

PrecompiledApp.config

im Stammordner Ihrer App, sonst könnten Sie auch bekommen HTTP Error 403.14.

Eine andere mögliche Lösung, wenn Sie sich in Ihrer global.asax bewegen, stellen Sie sicher, dass das Markup auf die richtige MvcApplication-Klasse verweist. Hoffentlich wird dies in Zukunft jemanden retten.

Ich hatte die WebDeploy IIS-Erweiterung verwendet, um meine Websites von IIS6 nach IIS7.5 zu importieren, sodass alle IIS-Einstellungen genau so waren, wie sie in der Produktionsumgebung waren. Nachdem ich alle hier bereitgestellten Lösungen ausprobiert hatte, von denen keine für mich funktionierte, musste ich einfach die App Pool-Einstellung für die Website von Classic auf Integrated ändern.

Ich habe plötzlich das gleiche 404.14-Problem festgestellt. Schließlich wurde das Problem behoben, indem das Kontrollkästchen "Beim Veröffentlichen vorkompilieren" in den Einstellungen für das Veröffentlichungsprofil deaktiviert war.

Ich habe meine Standardroute an einem Punkt geändert von:

routes.MapRoute(
"Default",
    "{controller}/{action}/{id}",
    new { controller = "Home", action = "Index", id = UrlParameter.Optional }

Zu:

routes.MapRoute(
"Default",
    "{controller}/{action}/{id}",
    new { controller = "Home", action = "Index" }

Welches gab mir Ihren Fehler. Ich bin froh, dass jemand das Routing erwähnt hat, weil ich wahrscheinlich für immer dabei gewesen wäre.

In meinem Fall ist ASP.NET 4.5 nicht auf dem Server installiert, daher wurde das Problem durch die Installation von ASP.NET 4.5 behoben.

Sie können diesen Fehler beheben, indem Sie cmd als admin als ausführen

Machen Sie dasselbe wie im Bild für Windows 32 Bit

Nehmen Sie einfach Änderungen in 64-Bit als Framework64 anstelle von nur Framework vor. Gehen Sie dann zu iis und aktualisieren Sie die Site. Wenn Sie immer noch einen Fehler haben, nehmen Sie Änderungen im Anwendungspool vor

Ich hatte ein anderes Problem, das zu diesem Problem führte.

• Ich hatte sichergestellt, dass in meinem App-Pool .net 4 im integrierten Modus ausgeführt wurde
• Ich hatte aspnet_regiis.exe -i ausgeführt
• Ich hatte überprüft, ob die Ordnerberechtigungen für das Konto, auf dem mein App-Pool ausgeführt wird, korrekt festgelegt wurden

Keines dieser Dinge funktionierte. Es stellte sich heraus, dass ich in meiner web.config unter system.webserver> modules Folgendes hatte:

<remove name="WindowsAuthentication" />

Offensichtlich wurde dadurch das Windows-Authentifizierungsmodul entfernt, das irgendwie alles aus dem Gleichgewicht zu bringen schien.

Ich hoffe das hilft jemandem, da mich das fast den ganzen Abend gekostet hat!

Die Benutzeroberfläche ist in den neueren Versionen von Windows Server etwas anders. Hier müssen Sie ASP.Net aktivieren, damit es unter IIS funktioniert

Hinzufügen einer weiteren Lösung für dieses Problem.

In meiner Global.asax.cs-Datei hatte ich versucht, dass versuchte PHP-Dateien von der MVC-Pipeline wie folgt verwendet werden:

routes.IgnoreRoute( "{*php}" );

Ich hatte dies zuvor in einem MVC2-Projekt getan und es funktionierte einwandfrei, aber dies in meiner MVC 3-App zu tun, verursachte das oben gemeldete Problem.

Ein weiterer Grund, warum dies passieren kann - Ihre RouteConfig.csoder WebApiConfig.cssind ungültig.

In meinem Fall hatte ich eine Route als solche definiert (beachten Sie die Klammer anstelle der geschweiften Klammer):

...
routeTemplate: "api/(something}"
...

Beachten Sie, dass Sie für Windows 8-Benutzer Windows-Komponenten hinzufügen / entfernen und die Version des .net-Neustarts entfernen und anschließend neu installieren müssen, um sie bei IIS zu registrieren. Ich gehe davon aus, dass dies passiert, wenn Sie .net 4.5 von Visual Studio erhalten und anschließend IIS installieren.

So seltsam es auch scheinen mag, die Neuinstallation von IIS hat bei mir funktioniert. Der folgende Befehl wurde im Ordner ".net version" ausgeführt:

aspnet_regiis.exe /i

Als ich diesen Befehl zum ersten Mal ausführte, wurde der HTTP-Fehler 403.14 angezeigt. Aber sobald ich den Befehl erneut ausgeführt habe, wurde das Problem behoben.

Obs : Eine andere Sache, die ich auch getan habe, war, HTTP Redirect von den Serverfunktionen im Serververwaltungsbildschirm zu entfernen, bevor IIS erneut installiert wurde. Vielleicht hatte dies auch Auswirkungen auf die Lösung des Problems, aber ich bin mir nicht sicher. Wenn die Neuinstallation von IIS immer noch nicht funktioniert, entfernen Sie die HTTP-Umleitung und versuchen Sie es erneut. Hoffentlich funktioniert es auch bei Ihnen.

Um dieses Problem zu lösen, ohne auf den 32-Bit-Modus zurückgreifen zu müssen, müssen Sie den Quellcode für dieses Projekt aktualisieren

public static void RegisterUrlRoutesFromAttributes(RouteCollection routes)
{
    // Enumerate assembly for UrlRoute attributes.
    List<MapRouteParams> routeParams = new List<MapRouteParams>();
    AppDomain.CurrentDomain.GetAssemblies()
        .ToList()
        .ForEach(assembly => routeParams.AddRange(GetRouteParamsFromAttributes(assembly)));

Ich habe dieses Problem als Diskussion im Diskussionsforum des IT-Cloud-Codeplex-Projekts angesprochen.

http://itcloud.codeplex.com/discussions/262000

Dies hat bei mir funktioniert und könnte für einen anderen nützlich sein.

Möglicherweise sind nicht alle erforderlichen Komponenten vorhanden oder / und nicht alle sind korrekt registriert. Um dieses Problem zu beheben, deaktivieren Sie alle Optionen in der Systemsteuerung -> Windows-Funktionen aktivieren oder deaktivieren -> Internetinformationsdienste -> World Wide Web Services -> Anwendungsentwicklungsfunktionen, deaktivieren Sie alle Optionen und aktivieren Sie alle erneut. Setzen Sie dann IIS und zurück Überprüfen Sie, ob das Problem behoben ist.

Wenn Sie IIS 8.5 unter Windows 8 oder Server 2012 ausführen, funktioniert mvc 4/5 (.net 4.5) möglicherweise nicht in einem virtuellen Verzeichnis. Wenn Sie einen lokalen Hosteintrag in der Hostdatei erstellen, der auf Ihren lokalen Computer verweist, und dann eine neue lokale IIS-Website auf diesen Ordner verweisen (mit dem passenden Hostheadereintrag), funktioniert dieser dann.

Ich habe einen neuen Namespace (und damit einen Ordner) erstellt, der mit der Route zu einem Controller (z . B. MvcApp/Test/SomeClasses.csund MvcApp/Controllers/TestController.cs) identisch ist . Dies führte auch zu einem 403.14!

Für mich bestand die Lösung darin, das NuGet-Paket Microsoft.AspNet.WebPages (plus die Abhängigkeiten von Rasiermesser und Infrastruktur) zu meinem Webprojekt hinzuzufügen.

Die Infrastruktur musste zwangsweise neu installiert werden, da sie zunächst nicht als Referenz hinzugefügt wurde.

In meinem Fall wurde die .NET CRL-Version im Anwendungspool prppertires auf Kein verwalteter Code festgelegt (ich weiß nicht warum). Durch Festlegen auf .NET CRL Version v4.0.30319 wurde das Problem behoben.