it-swarm.com.de

ASP.NET 4.5 MVC 4 funktioniert nicht unter Windows Server 2008 IIS 7

Offenbar fehlt mir etwas. Ich kann eine einfache ASP.NET MVC 4, .NET 4.5-App auf einem Windows Small Business Server 2008 unter IIS 7 nicht bereitstellen.

.NET Framework 4.5 ist installiert.

Soll ich diese Version (4.5) in den Grundeinstellungen des Anwendungspools der Anwendung sehen? Zu diesem Zeitpunkt habe ich nur 2.0 und 4.0, da 4.5 wie das 3.5 ist, das nur zusätzlich zum 4.0-Framework hinzugefügt wird, denke ich, dass dies normal ist.

Beim Durchsuchen der Homepage wurde folgende Fehlermeldung angezeigt:

403 - Verboten: Zugriff verweigert. Sie sind nicht berechtigt, dieses Verzeichnis oder diese Seite mit den von Ihnen angegebenen Anmeldeinformationen anzuzeigen.

Wenn ich den einzigen Controller mit dem Namen Page/page/index anfordere, erhalte ich die Seite 404 not found. Wie der ASP.NET-Prozess nie die http-Anfrage erhalten.

Ich kann eine einfache HTML-Seite anfordern.

Der Anwendungspool ist auf .NET 4.0 und Integriert als verwalteter Pipeline-Modus festgelegt.

NETWORK SERVICE hat Lese-/Schreibzugriff auf das Verzeichnis.

Die App funktioniert natürlich ab VS2012 einwandfrei.

Ich habe keine Ahnung, was hier nicht stimmt, und Suchmaschinenabfragen helfen nicht viel.

Hat jemand einen Tipp, der wäre sehr dankbar. Vielen Dank

Bearbeiten

Die DLLs befinden sich bereits im Bin-Ordner wie System.Web.Mvc, System.Web.Razor usw.

Ich habe eine leere Seite test.aspx erstellt, um sicherzustellen, dass der asp.net-Arbeitsprozess die Anforderung erhält, und ja, die Seite war in Ordnung. Es scheint also, dass das MVC-Routing nicht funktioniert, obwohl die ASP.NET MVC 3-Webanwendung auf diesem Server einwandfrei funktioniert.

Nach der Installation von .NET 4.5 habe ich eine aspnet_regiis -iru erstellt, die der App einen aspnet_client-Ordner hinzugefügt hat, aber das Problem wird dadurch immer noch nicht behoben.

Die anonyme Authentifizierung ist im Abschnitt IIS Authentifizierung) aktiviert, und die Autorisierungsanzeige lässt alle Benutzer zu.

ASP.NET MVC 4 ist installiert. Ich habe gerade eine Reparatur durchgeführt, um sicherzugehen.

Obwohl ASP.NET MVC 4 installiert ist, wird der 404-Fehler beim Anfordern der Aktion/page/index vom Standard IIS und nicht vom Standardaspnet-Fehler zurückgegeben. Daher sieht er tatsächlich wie der MVC aus 4 framework ist nicht richtig installiert, da ich es nur noch einmal überprüfe und eine Reparatur durchführe. Wo kann ich weiter nachforschen?

@Mystere Man, ich habe die anonyme Authentifizierung geändert, um die Identität des Anwendungspools zu verwenden, die App zu beenden, zu starten und trotzdem den gleichen Fehler zu machen. Es sieht wirklich so aus, als würde ASP.NET MVC 4 die Anfrage nicht entgegennehmen.

Hier ist ein Teil der web.config:

  <system.webServer>
    <validation validateIntegratedModeConfiguration="false" />
    <handlers>
      <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>
  <runtime>
    <assemblyBinding xmlns="urn:schemas-Microsoft-com:asm.v1">
      <dependentAssembly>
        <assemblyIdentity name="System.Web.Helpers" publicKeyToken="31bf3856ad364e35" />
        <bindingRedirect oldVersion="1.0.0.0-2.0.0.0" newVersion="2.0.0.0" />
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="System.Web.Mvc" publicKeyToken="31bf3856ad364e35" />
        <bindingRedirect oldVersion="1.0.0.0-4.0.0.0" newVersion="4.0.0.0" />
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="System.Web.WebPages" publicKeyToken="31bf3856ad364e35" />
        <bindingRedirect oldVersion="1.0.0.0-2.0.0.0" newVersion="2.0.0.0" />
      </dependentAssembly>
    </assemblyBinding>
  </runtime>
  <entityFramework>
    <defaultConnectionFactory type="System.Data.Entity.Infrastructure.SqlConnectionFactory, EntityFramework" />
  </entityFramework>

Bearbeiten 27.09.2012

Ich habe Microsoft Framework .NET 4.5 erneut gepaart und das ASP.NET MVC 4 repariert, die einfache ASP.NET MVC 4-App erneut bereitgestellt und immer noch das gleiche Verhalten. Ich bin mir nicht sicher, was ich als nächstes tun soll, und habe ein Kopfgeld gezahlt, in der Hoffnung, dass mir jemand helfen könnte, das Problem zu finden.

Bearbeiten 31.01.2014

Als ich diese Frage stellte, markierte ich runAllManagedModulesForAllRequests als akzeptierte Antwort, da das Problem dadurch behoben wurde. Aber ich würde das sicherlich nicht in der Produktion verwenden. Ich frage, warum ich das tun musste und hatte keine Antworten.

Als Martin Hollingsworth Antwort war wirklich das, wonach ich gesucht habe, ein guter Weg, um dieses Problem zu beheben, ohne alle Leistungsprobleme im Zusammenhang mit runAllManagedModulesForAllRequests.

Wir haben fast aufgegeben und einen neuen Windows 2012-Server gekauft (von dem aus die ASP.NET MVC-App so funktioniert, wie sie ist). Nach dem Testen von Martins Lösung funktionierte der Windows 2008-Server.

53

Wenn Sie das QFE von kb 980368 nicht anwenden können , anstatt das runAllManagedModulesForAllRequests zu verwenden ) wie in der akzeptierten answer vorgeschlagen, sollten Sie die Modulkonfiguration mit preCondition = "" verwenden, um die negativen Auswirkungen auf die statische Aufladung zu vermeiden Inhalt wie in den Blog-Posts beschrieben Wie ASP.NET MVC Routing funktioniert und wie es sich auf die Leistung statischer Anforderungen auswirkt und Verwenden Sie nicht runAllManagedModulesForAllRequests = "true", wenn Sie Ihre MVC abrufen routing to work und einige kommentare zu den antworten.

Der Blogeintrag von Scott Hanselman über runAllManagedModulesForAllRequests sollte diesem Argument etwas Gewicht verleihen. Rick Strahl's post Vorsichtsmaßnahmen bei den runAllManagedModulesForAllRequests in IIS 7/8 ist die beste Erklärung für die Interaktion zwischen den Einstellungen I gefunden haben. Lesen Sie auch die IIS Dokumentation zum module preCondition Attribut .

Denken Sie daran, dass diese Konfigurationsänderung nicht erforderlich ist, wenn Sie das QFE angewendet haben, da dieses Verhalten zum Standard wird.

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

Versuchen Sie Folgendes:

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

BEARBEITEN:

Die obige Lösung funktioniert für .NET 3.5 oder niedriger. Wenn Sie .NET 4.0 oder höher verwenden, können Sie versuchen Installation von IIS7 QFE

Auch dieser Artikel ist lesenswert, um den Unterschied zwischen diesen beiden zu verstehen.

47
kdrvn

Ich hatte ein ähnliches Problem. Ich habe viele der hier beschriebenen Lösungen (den Konfigurationseintrag Web.Config system.webServer usw.) ohne Erfolg ausprobiert. Am Ende entdeckte ich das Problem mit meiner speziellen Installation. Ich habe meine Website im lokalen Dateisystem veröffentlicht und diese Dateien dann auf den Server kopiert. Es stellte sich heraus, dass die Datei Global.asax nicht Teil der veröffentlichten Dateien war. Nachdem ich diese Datei kopiert hatte, verschwand der Fehler.

9
Jesus Diaz

Gemäß https://stackoverflow.com/a/12521807/695829

Ich hatte das gleiche Problem und dieses Hotfix hat es behoben:: http://support.Microsoft.com/kb/980368

3
Daniel de Zwaan

Wie von SonicTheLichen erwähnt, wird beim Veröffentlichen in Visual Studio die Datei gloabal.asax nicht standardmäßig kopiert. Durch Kopieren der Datei global.asax auf Ihren Webserver sollte das Problem behoben sein. Vielen Dank an SonicTheLichen für den Beweis der Lösung.

Grüße, Saurabh

1
user3565848

Ich weiß nicht, ob dies Ihr Problem beheben wird, aber es behebt ein Problem, das ich mit der Bereitstellung und MVC-App für IIS hatte.

Ich musste der aspnet_isapi.dll eine Platzhalteranwendungszuordnung für das Ausgangsverzeichnis/virtuelle Verzeichnis der Anwendung hinzufügen. Klicken Sie dazu mit der rechten Maustaste auf die Website/das virtuelle Verzeichnis, wählen Sie die Registerkarte Basisverzeichnis/virtuelles Verzeichnis aus, klicken Sie auf die Konfigurationsschaltfläche und klicken Sie dann auf die Schaltfläche Einfügen im Abschnitt Platzhalteranwendungszuordnungen.

C:\WINDOWS\Microsoft.net\Framework64\v4.0.30319\aspnet_isapi.dll

Viel Glück!

0
BlakeH

Ich musste Skripte im Abschnitt Handlerzuordnung der Websiteeigenschaften in IIS aktivieren.

Handler Mappings

Öffnen Sie IIS und klicken Sie auf die betreffende Website. Öffnen Sie die Handlerzuordnungen und klicken Sie auf "Funktionsberechtigungen bearbeiten". Aktivieren Sie die Kontrollkästchen für "Skript" und "Ausführen" und klicken Sie auf "OK". Gut zu gehen!

0
BenM

Ich hatte ein ähnliches Problem. Ich musste eine .net MVC-Site auf einem neuen Server mit Windows 2008 und IIS 7.5 installiert. Als ich die Programme und Funktionen überprüfte, stellte ich fest, dass nur das .Net Framework 4.5.1 installiert war Ich habe die .Net 3.5.1-Windows-Funktion manuell aktiviert. Nach der Installation von MVC 4.0 funktionierte das Routing nicht mehr.

Meine Lösung:
1) Deinstallieren Sie das .Net 4.5.1 Framework und MVC 4.0
2) Installieren Sie das .Net Framework 4.0
3) Installieren Sie das .Net Framework 4.5.1
4) Installieren Sie MVC 4.0

0

Ich weiß, dass dies alt ist, aber Windows-Updates haben gerade ein paar Stunden für mich verschwendet:

WENN Sie Ihre Ausnahmen in Global.asax behandeln, kann dies auch einfach sein, da Windows-Updates genauso wie Ihre Entwicklungsumgebung beibehalten werden. was mein global.asax versucht hat zu handhaben und hatte wiederum das gleiche problem aber versteckt das zugrunde liegende problem .....

0
user1515791