Ich habe gerade versucht, meine erste Webanwendung unter IIS auf meinem Windows 7 Home Premium-Notebook bereitzustellen. Nach dem Erstellen der Anwendung musste ich zum klassischen Anwendungspool wechseln und diesen Pool dann für Framework 4.0 einrichten. Nun bekomme ich folgende Fehlermeldung:
HTTP-Fehler 404.17 - Nicht gefunden Der angeforderte Inhalt scheint .__ zu sein. Skript und wird nicht vom statischen Dateihandler bereitgestellt.
Die angeforderte URL lautet http: // localhost: 80/pvmms/default.aspx
Ich fürchte, das ausgiebige Googeln hat mir nichts klares oder definitives zur Folge, und ich habe mich wie üblich an die Experten gewandt.
EDIT: Ich vermute, das liegt daran, dass es keine Framework-4.0-Handlerzuordnungen für ASPX-Dateien gibt. Aspnet_regiis gibt meinem Admin-Benutzer jedoch sogar den Finger und sagt, ich brauche Administratorrechte, um es auszuführen.
EDIT # 2: Ich habe alle Frameworks (2 & 4, 32 und 64) registriert und jetzt funktioniert alles. Ich habe dies gefunden, indem ich manuell eine Skriptzuordnung für .aspx
zu aspnet_isapi und voila hinzugefügt habe. Ich verstehe nicht, warum die Installation des Frameworks dies nicht tut, es sei denn, mein Speicher schlägt fehl und ich habe IIS erst nach der Installation von VS aktiviert.
Vielleicht jetzt zu spät, aber meistens müssen Sie laufen
aspnet_regiis.exe -i
nach der Installation von asp.net. Vielleicht würde ich es jetzt trotzdem machen.
Wenn Sie WCF-Unterstützung benötigen, müssen Sie möglicherweise Folgendes ausführen:
c:\Windows\Microsoft.NET\Framework\v3.0\Windows Communication Foundation\ServiceModelReg.exe -i
Ersetzen Sie v3.0 in Ihrer aktuellen Framework-Version.
Beim Versuch, auf einen von mir geschriebenen WCF-Dienst zuzugreifen, ist dieser Fehler in IIS 8.5 aufgetreten. Es stellte sich heraus, dass auf dem Server die WCF-HTTP-Aktivierungsfunktionen nicht aktiviert waren. Aktivieren Sie die Kontrollkästchen und klicken Sie durch den Assistenten, "iisreset". Die Arbeit begann.
Wenn Sie iis verwenden 7.5.
Gehen Sie einfach zum IIS Manager und öffnen Sie Ihre Website-Eigenschaften.
Dort sehen Sie den Abschnitt 'Handler-Zuordnungen'. Gehen Sie einfach zu diesem Abschnitt und suchen Sie nach 'staticFile'.
Wahrscheinlich ist es eine letzte Datei in der Liste.
Klicken Sie dann mit der rechten Maustaste darauf und wählen Sie "Zurücksetzen zu übergeordneten Elementen".
Ich habe so viele Stunden verschwendet, als ich das erste Mal begegnet bin. Auf jeden Fall wird das Ihr Problem lösen.
Ich hatte dieses Problem mit Windows Server 2012 mit ASP .NET 4.5. Sie können aspnet_regiis.exe nicht verwenden und müssen nur ASP .NET 4.5 über den Assistenten zum Hinzufügen von Rollen und Features installieren:
Sie finden den Menüpunkt "Rollen und Features hinzufügen" im Menü "Verwalten" in der rechten Ecke des Server-Managers
Ich weiß, dass dies eine alte Frage ist, aber ich hatte dies gerade mit einer 3.5-Anwendung auf meinem umgebauten Windows-8-Computer, und ich bekam dies immer noch nach aspnet_regiis -iru
und es stellte sich heraus, dass ASP.NET 3.5 in Application Development nicht angekreuzt war Features (nicht genügend Ruf, um ein Bild zu veröffentlichen).
sollte diese Option ausprobieren, nehme ich an
Ich habe dieses Problem durch Aktivieren von WCF Services
gelöst.
Programs and Features > NET Framework 4.5 Services > WCF Services> HTTP Activation node
Aber man muss zugeben, dass die Jungs diese ENTIRE IIS - Konfiguration konfigurieren/raten/probieren und versuchen/versuchen, dies/try auszuprobieren, das 4 oder 5 unserer Tage mit dem Versuch sucht, eine Lösung zu finden IS A COMPLETE AND UTTER JOKE.
FREUDE, 'IIS' IS DER GRÖSSTE VERTRAUENS-TRICK, DER IMMER AM MANKIND TO DATE GESPIELT WURDE
Es besteht die Möglichkeit, dass der für Ihre Anwendung standardmäßig erstellte Anwendungspool die Version 2 ist. Obwohl Sie in der Liste einen Handler für die Erweiterung .svc sehen, funktioniert sie nicht und behandelt sie als statische Datei. Sie müssen lediglich die Eigenschaften des Anwendungspools öffnen und auf Version 4 umstellen.
Registrieren Sie sich erneut asp.net .... löst das Problem.
Wechseln Sie zur Eingabeaufforderung von Visual Studio.
Registrieren Sie asp.net als Windows\Microsoft.net\Framework [.Net-Versionsnummer]\aspnet_regiis.exe -i
Ich hatte das gleiche Problem auf einer Windows 8-Maschine, die ich gerade aufstelle. Ich hatte vs2012 vor vs2010 installiert, wodurch .NET Framework 4.5 installiert wird. Ich habe meine App-Pools in 4.0 ausgeführt. Ich stellte sicher, dass ich aspnet für 4.0 mit aspnet_regiis -i registriert hatte. Das hat immer noch nicht funktioniert. Dann öffnete ich die Windows-Funktionen und bemerkte, dass 4.5 einen Satz namens ".NET Framework 4.5 Advanced Services" hinzufügte. Ich habe den WCF-Dienstknoten und seine untergeordneten Elemente aktiviert, und mein svc-Endpunkt funktionierte ordnungsgemäß. Ich hoffe, das hilft Leuten, die auf Windows 8 umsteigen.
Ich stolperte über diese Frage, als ich auf dieselbe Frage stieß. Die Hauptursache für mein Problem war ein falsch konfigurierter App-Pool. Es wurde versehentlich auf 2.0 eingestellt, als es auf 4,0 eingestellt werden musste. Die Antwort unter dem folgenden Link hat mir geholfen, dieses Problem aufzudecken: http://forums.iis.net/t/1160143.aspx
Für andere Leute, die dies lesen:
Dies kann passieren, wenn die .Net-Version, die Sie registriert haben, nicht unter den "Grundeinstellungen" des mit Ihrer Website verbundenen Anwendungspools ausgewählt wurde. Beispielsweise wurde in Ihrem Standortanwendungspool .Net v2.0 ausgewählt, Sie haben jedoch v4.0 registriert
Ich hatte das gleiche Problem. Wenn ich statische Inhalte für IIS hinzugefügt habe, funktioniert es einwandfrei.
Nur eine andere mögliche Lösung, die ich gefunden habe, hatte die gleiche Fehlermeldung.
Beim Versuch, eine .NET 4.0-Webanwendung für einen neuen Anwendungspool einzurichten, wurde mir dieser seltsame Fehler angezeigt, der besagte, dass meine ASPX-Datei mit dem statischen Dateihandler verarbeitet werden sollte, was keinen Sinn machte.
Aus irgendeinem Grund wurde ISAPI für .NET 4.0 im Bereich ISAPI und CGI Restrictions der Serverebene im Manager IIS deaktiviert. Es wurde alles auf aktiviert gesetzt , aber der IIS 7.5-Manager ist so kompliziert und schwer zu verfolgen, dass ich lange brauchte, um das herauszufinden.
Ich vermute, dass der statische File-Handler standardmäßig verwendet wurde, da es sich um eine 4.0-Anwendung handelte, die von der 4.0-Engine nicht verarbeitet werden konnte.
Für Windows 10/Framework 4.7 musste ich die HTTP-Aktivierung mit der folgenden Methode aktivieren:
cmd -> Rechtsklick -> Als Administrator ausführen
C:\Windows\Microsoft.NET\Framework\v4.0.30319\aspnet_regiis.exe -i
Mit IIS manager habe ich festgestellt, dass .aspx-Dateien (unter "Handler-Mappings") zu ISAPI 2.0 zugeordnet wurden - obwohl ASP.NET 4.5 zuvor installiert war. Wenn Sie sie so bearbeiten, dass sie (auch) auf eine ausführbare Datei für ISAPI 4.0 64bit zeigen, wurde das Problem behoben.
Die ausführbare Datei wurde in % Windir%\Microsoft.NET\Framework64\v4.0.30319\aspnet_isapi.dll gefunden
Ich hatte das gleiche Problem. Ich habe gerade die Version des Zielframeworks auf der Website in die Version geändert, in der sie entwickelt wurde. Das hat mein Problem gelöst. Hoffe das hilft...
Danke dir
ich erhielt diese Nachricht für eine Anwendung unter iis 7.5 mit einem klassischen App-Pool, der .net 2.0 zugewiesen ist. Ich musste zu Handler-Mappings gehen und zwei Skript-Maps hinzufügen. Beide waren bis auf den Namen gleich. ein Name war svc-ISAPI-2.0-64, der andere war svc-ISAPI-2.0. Der Anforderungspfad war .svc. Die ausführbare Datei lautete% SystemRoot%\Microsoft.NET\Framework64\v2.0.50727\aspnet_isapi.dll. Ich habe IIS neu gestartet und alles war glücklich
in meinem Fall kann es mehrere Gründe geben, und zwar unter Anwendungspool -> Voreinstellung -> 32-Bit-Anwendung aktivieren (sollte wahr sein).
Eines der schlimmsten Fälle, das ich gerade gelöst habe, ist der Konflikt mit dem Eintrag in Web.config.
Auf meinem lokalen Computer hatte ich nicht die .woff-Erweiterung in IIS registriert, also habe ich sie mit Web.config hinzugefügt. Auf dem Produktionsserver hatte .woff den MIME-Typ registriert. Dies verursachte einen Konflikt auf Anwendungsebene.
Ein lustiger Teil ist, dass dafür keine Fehler protokolliert werden. Nur eine Vermutung (zum ersten Mal natürlich).
Für mich war die Lösung also einfach, und/oder Elemente aus der web.config zu entfernen.