MVC4 HTTP-Fehler 403.14 - Verboten

Ich habe eine .net4.5 ASP.NET MVC4-Webanwendung erstellt, die lokal einwandfrei funktioniert (IIS Express- und Entwicklungsserver), aber sobald ich sie auf meinem Webserver bereitstelle, wird der Fehler 403 ausgegeben. Ich habe .Net 4.5RC auf dem Server installiert und sogar das aspnet_regiis -i Bit ausprobiert, das jeder für seine Probleme mit früheren Versionen von MVC / .Net empfohlen hat, aber es hat nicht geholfen.

Irgendwelche Ideen?

EDIT : Mehr Infos zur Situation. Der Server ist 32bit und ich habe 4 andere MVC3-Anwendungen, die gut funktionieren. Es ist nur meine MVC4-App, die nicht funktioniert.

Versuchen

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

Über

/server/405395/unable-to-get-anything-except-403-from-a-net-4-5-website

Fehler 403.14 ist der HTTP-Fehlercode, mit dem der Inhalt eines Verzeichnisses nicht aufgelistet werden darf. Bitte stellen Sie sicher, dass

1. Sie haben die Website als Anwendung in IIS eingerichtet
2. Sie haben .NET 4.5 auf dem Server installiert
3. Sie haben den Anwendungspool so eingestellt, dass die richtige Version des .NET Frameworks ausgeführt wird (dh, er ist nicht auf .NET 2.0 festgelegt
4. Sie verwenden die integrierte Pipeline in Ihrem Anwendungspool
5. .NET 4.5 ist tatsächlich in IIS registriert. In diesem Beitrag finden Sie ein ähnliches Problem / eine ähnliche Lösung

Normalerweise sind a und d die größten Probleme bei MVC-Bereitstellungen in IIS

Vielleicht ... Wenn Sie zufällig den Veröffentlichungsassistenten verwenden (wie ich) und das Kontrollkästchen "Während der Veröffentlichung vorkompilieren" aktivieren (wie ich) und dieselben Symptome sehen ...

Ja, ich habe mich über den Kopf geschlagen, aber nachdem ich dieses Kontrollkästchen deaktiviert habe, eine scheinbar nicht verwandte Einstellung, verschwinden alle beschriebenen Symptome nach der erneuten Bereitstellung.

Hoffentlich behebt dies einige Leute.

Windows-> Start -> Witwenfunktionen ein- und ausschalten

Stellen Sie sicher, dass Sie die erforderlichen Optionen aktivieren

Vor der Bewerbung

runAllManagedModulesForAllRequests="true"/>

Betrachten Sie den folgenden Link, der eine weniger drastische Alternative vorschlägt. In dem Beitrag bietet der Autor die folgende Änderung an der lokalen web.config an:

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

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

In Visual Studio 2012 gibt es einen Refactor -> Rename Bug , der die "id" im Literal-String- Wert des URL-Parameters in meiner RouteConfig.cs fälschlicherweise umbenannt hat. Dies führte zu einem 403.14 bei einem neuen und ansonsten korrekten Setup in Windows Server 2012 und Windows Server 2008 R2.

routes.MapRoute(
    name: "Default",
    url: "{controller}/{action}/{id}",
    defaults: new { controller = "Home", action = "Index", id = UrlParameter.Optional }
);

wurde geändert in

routes.MapRoute(
    name: "Default",
    url: "{controller}/{action}/{renamed_text}",
    defaults: new { controller = "Home", action = "Index", id = UrlParameter.Optional }
);

Sie können auch eine 403 erhalten, wenn Sie beim Testen mit einem Dev-Server eine integrierte Pipeline verwenden und diese dann als klassischen Pipeline-Modus auf Ihrem Live-IIS 7.5-Webserver installieren. Außerdem fehlte mir der Ordner app_data, der ebenfalls erforderlich war

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 in der Hostdatei einen lokalen Hosteintrag 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.

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

Sie können den obigen Code verwenden

Ich hatte den Anwendungspool der neuen App auf den DefaultAppPoolin IIS eingestellt, mit dem offensichtlich die ClassicPipeline verwendet wird .NET v.2.0.

Um das Problem zu lösen, habe ich mithilfe der IntegratedPipeline und einen neuen App-Pool erstellt .NET v4.0. Nur für diese neue Anwendung und dann fing alles an, wie erwartet zu funktionieren.

Vergessen Sie nicht, diesen neuen App-Pool der Anwendung zuzuweisen. Wählen Sie die Anwendung in IIS aus, klicken Sie auf Basic Settingsund wählen Sie dann den neuen App-Pool für die App aus.

Das, was ich in letzter Zeit häufiger sehe, ist IIS und ermöglicht die Ausführung von 32-Bit-Anwendungen

Ist es das, was du versucht hast? Andernfalls benötigen wir weitere Informationen zu Produktions- und Entwicklungsserverversionen

Ich habe ein etwas anderes Problem. Auf Server 2012 habe ich irgendwie vergessen, asp.net 4.5 zu aktivieren. Wenn Sie dieses Problem haben, überprüfen Sie, ob Sie es aktivieren.

Ich verwende Windows Server 2012 R2 unter Azure und ASP.NET 4.5, IIS 8

Ich habe dieses Problem gelöst, indem ich alle ASP.NET-Elemente in Programme und Funktionen deinstalliert und dann ASP.NET wie folgt mit dem Server-Manager mithilfe von Rollen und Funktionen neu installiert habe: Auswahl der rollenbasierten oder funktionsbasierten Installation, Auswahl meines Servers und dann Wählen Sie für Serverrolle auswählen die Option Webserver (IIS) / Webserver / Anwendungsentwicklung aus, klicken Sie auf ASP.NET 4.5, bestätigen Sie die Installation einer Voraussetzung und installieren Sie ASP.NET 4.5 erneut.

Meine früheren Suchanfragen hatten mich zu der Annahme geführt, dass das Problem tatsächlich auf ein Registrierungsproblem bei ASP.NET zurückzuführen ist. In früheren Versionen von ASP.NET gibt es tatsächlich ein Dienstprogramm, mit dem Sie ASP.NET registrieren können, ohne es erneut zu installieren. Dieses Dienstprogramm scheint jedoch nicht mehr verfügbar zu sein.

Ich löse das Problem beim Öffnen des Visual Studios, beim Erweitern der Referenzen und beim Ändern der Eigenschaft "Copy Local" in "True".

Ich stelle fest, dass ich die DLLs der alten Version mit den DLLs meiner neuen Version vergleiche (das hat nicht funktioniert).

In meinem Fall war die Standardseite meiner Anwendung index.html, die in den Standarddokumentoptionen fehlte. Durch Hinzufügen wurde der Fehler 403.14 Verboten behoben.

In meinem Fall wurde das Problem durch ein benutzerdefiniertes ActionFilterAttribute verursacht, das eine Art globales Filterattribut war. Das Attribut hat einen Dienst über Autofac instanziiert, aber der Dienst ist im Konstruktor abgestürzt:

public ActionFilterAttribute()
{
    _service = ContainerManager.Resolve<IService>();
}

public class Service: IService
{ 
    public Service()
    {
        throw new Exception('Oops!');
    }
}

In meinem Fall haben weder Windows-Funktionen noch aspnet_regiis -idie Arbeit nicht erledigt. Nach stundenlangem Stöbern im Internet habe ich meine eigene Lösung gefunden:

1. Im IIS-Manager in Modulen habe ich die Vererbung in lokal im Knoten UrlRoutingModule-4.0 geändert:

   

2. In web.config habe ich eine Mischung aus einigen Tipps aus diesem Forum eingefügt:

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

Ich hoffe es hilft