Das Debuggen auf dem Webserver kann nicht gestartet werden. Das ASP.NET-Debugging für VS 2010, II7, Win 7 x64 konnte nicht gestartet werden

Ich verwende Visual Studio 2010 (als Administrator), IIS 7 unter Windows 7 x64. Ich kann die ASP.NET-Website in IIS 7 ohne Debugging ausführen, aber wenn ich zum Debuggen F5 drücke, erhalte ich Folgendes:

Das Debuggen auf dem Webserver kann nicht gestartet werden. Das ASP.NET-Debugging konnte nicht gestartet werden. Weitere Informationen erhalten Sie möglicherweise, indem Sie das Projekt ohne Debugging starten.

Leider hilft mir der Hilfelink nicht viel und führt einen verdammt großen Baum von Dingen hinunter.

Ich habe Folgendes überprüft:

• Sicherheitsanforderungen - Ich kann mich nicht erinnern, vorher etwas Besonderes tun zu müssen. Der Arbeitsprozess in IIS7 ist w3wp.exe. Es heißt, wenn es als ASPNET- oder NETWORK-SERVICE ausgeführt wird, muss ich über Administratorrechte verfügen, um es zu debuggen. Wie finde ich heraus, ob ich hier etwas ändern muss?

• Website-Eigenschaftenseiten> Startoptionen> Debugger> ASP.NET ist aktiviert. Benutzerdefinierten Server verwenden wird auf die URL der Site festgelegt (was ohne Debugging problemlos funktioniert).

• Das Debuggen ist in aktiviert web.config.

• Die Anwendung verwendet ASP.NET 3.5 (ich möchte irgendwann auf 4.0 umsteigen, muss mich aber um eine Migration kümmern).

• Anwendungspool: Klassifizierung von .NET AppPool (auch DefaultAppPool ausprobiert).

Irgendwelche Ideen, wo ich als nächstes nachsehen kann?

Sicherlich sollte es nicht so schwierig sein, IIS, VS zu installieren, eine Website zu erstellen und mit dem Testen zu beginnen.

Danke im Voraus.

Gehen Sie zu IIS und überprüfen Sie, ob der von Ihnen verwendete App-Pool gestartet ist. Oft wird ein Fehler angezeigt, der den App-Pool herunterfährt. Sie müssen nur mit der rechten Maustaste klicken und starten, und schon kann es losgehen.

Es stellt sich heraus, dass der Schuldige das IIS Url Rewrite- Modul war. Ich hatte eine Regel definiert, die Aufrufe von Default.aspx (die als Startseite der Website festgelegt wurde ) an das Stammverzeichnis der Website umleitete, damit ich eine kanonische Home-URL haben konnte. Anscheinend hatte VS jedoch ein Problem damit und wurde verwirrt. Dieses Problem trat nicht auf, als ich Helicon ISAPI_Rewrite verwendete, sodass mir nicht einmal der Gedanke kam, dies zu überprüfen.

Am Ende habe ich eine ganz neue Website von Grund auf neu erstellt und Projekte / Dateien nach und nach in meine Lösung portiert und meine web.config neu erstellt, bis ich das herausgefunden habe! Nun, zumindest habe ich jetzt eine etwas sauberere Site mit .NET 4.0 (bis jetzt werde ich hoffentlich nicht auf Wände stoßen) - aber was für ein Schmerz!

Visual Studio versucht beim Start (aus irgendeinem Grund), auf die URL zuzugreifen:

/debugattach.aspx

Wenn Sie eine Umschreiberegel haben, die beispielsweise .aspxDateien umleitet (oder auf andere Weise abfängt), z. B. Dateien, wird dieser Fehler angezeigt. Die Lösung ist es, diesen Abschnitt zu Beginn Ihrer hinzufügen web.config‚s <system.webServer>/<rewrite>/<rules>Abschnitt:

<rule name="Ignore Default.aspx" enabled="true" stopProcessing="true">
    <match url="^debugattach\.aspx" />
    <conditions logicalGrouping="MatchAll" trackAllCaptures="false" />
    <action type="None" />
</rule>

Dadurch wird sichergestellt, dass diese eine bestimmte Anforderung abgefangen, nichts unternommen und vor allem die Ausführung gestoppt wird, damit keine Ihrer anderen Regeln ausgeführt wird. Dies ist eine robuste Lösung. Sie können diese also für die Produktion in Ihrer Konfigurationsdatei aufbewahren.

Zum Nutzen anderer hatte ich in meinem Fall den Anwendungspool so konfiguriert, dass meine Windows-Anmeldeinformationen verwendet werden, um auf eine Netzwerkressourcenfreigabe zuzugreifen. Seit dem letzten Debuggen der Lösung hatte ich mein Windows-Passwort zurückgesetzt. Geändertes Passwort im App-Pool und im Bada Bing gespeichert.

Wenn die ApplicationPool-Identität als benutzerdefiniertes Konto festgelegt und das Kennwort des Computers geändert wurde, müssen Sie Ihr Kennwort aktualisieren

In meinem Szenario wurden Änderungen am Abschnitt httpErrors in web.config vorgenommen und folgendermaßen festgelegt:

<httpErrors mode="Custom"> 

verursachte das Problem "Debugging auf dem Webserver kann nicht gestartet werden". Das Zurücksetzen auf den vorherigen Wert von "DetailedLocalOnly" hat das Problem behoben. Als ich etwas tiefer grub, stellte ich fest, dass es tatsächlich nur die 401-Fehlereinstellung war, die dies verursachte:

<httpErrors mode="Custom"> 
    <error statusCode="401" prefixLanguageFilePath="" path="/masterpages/500.html" responseMode="ExecuteURL" />
<httpErrors mode="Custom"> 

Das Auskommentieren der 401-Fehlerzeile hat das Problem ebenfalls behoben. Ich habe mich dafür entschieden, da ich dann die benutzerdefinierte Fehlerbehandlung beibehalten und mit dem Debuggen beginnen kann.

Ich habe immer noch keine Ahnung, warum das passiert.

Bitte überprüfen Sie den Anwendungspool. wenn es gestoppt ist. starte es neu.

Hatte das gleiche Problem beim Versuch, ein DNN-Modul (Dot Net Nuke) zu debuggen. Es stellte sich heraus, dass Sie Compilation debug = "true" benötigen:

<compilation debug="true" strict="false" targetFramework="4.0"> 

in Ihrer web.config. Standardmäßig ist es in DNN falsch. Originalquelle hier: http://www.dnnsoftware.com/forums/forumid/111/postid/189880/scope/posts

Ich habe genau das gleiche Problem nach der Implementierung des Rewrite-Moduls.

Wenn ich die Umschreibeinträge aus meiner Datei web.config entferne, funktioniert das Debuggen einwandfrei.

Um dies zu umgehen, kommentiere ich nur die Umschreibetags während des Debuggens wie folgt aus ...

<rewrite>
    <rules>
        <rule name="LowerCaseRule_1" stopProcessing="true">
            <match url="[A-Z]" ignoreCase="false" />
            <action type="Redirect" url="{ToLower:{URL}}" />
        </rule>
        <rule name="RedirectDefault.aspx_1" stopProcessing="true">
            <match url="(.*)default.aspx" />
            <action type="Redirect" url="{R:1}" redirectType="Permanent" />
        </rule>
    </rules>
</rewrite>

Ich entferne dann die Kommentare nach dem Debuggen.

Muss ein Fehler in Visual Studio 2010 sein.

Ich habe den gleichen Fehler erhalten, da der Anwendungspool in IIS gestoppt wurde. Nach dem Starten des App-Pools wurde das Problem behoben.

Folgendes habe ich getan, um den von Ihnen festgestellten Fehler zu beheben. Suchen Sie den Webordner für die App im Dateisystem, gehen Sie zu Eigenschaften => Sicherheit, klicken Sie auf die Schaltfläche Erweitert und dann auf die Registerkarte Besitzer , klicken Sie auf die Schaltfläche Bearbeiten und ändern Sie den Besitzer (mit den richtigen Berechtigungen) des Ordners und aktivieren Sie das Kontrollkästchen " Repalce " Eigentümer auf Subcontainern und Objekten "Kontrollkästchen. Klicken Sie auf " Übernehmen " und dann war ich im Geschäft (Debuggen möglich).

Hoffe, das funktioniert für jemand anderen.

Ich habe das gerade für meine einzige Lösung behoben, die dies hatte. Zwei der Projekte in der Lösung wurden als Standorte in IIS festgelegt. Ich habe ASP.Net Impersonation unter Authentifizierung für beide Projekte aktiviert ... und VIOLA! ENDLICH nichts mehr von diesem nervigen Fehler!

Ich habe in VS 2012 dieselbe Fehlermeldung erhalten, wurde jedoch nicht als Administrator ausgeführt. Als ich die App als Administrator ausführte, erhielt ich eine andere und etwas hilfreichere Nachricht (die ich herausfinden konnte). HTH

Wenn der App-Pool Probleme beim Neustart hat oder einfach nicht neu gestartet werden soll, überprüfen Sie, ob Windows kürzlich ein Update auf ASP.NET v4.0 oder einem anderen App-Pool durchgeführt hat. Das ist in meinem Fall passiert. Ich habe einfach meinen Computer neu gestartet, dann ASP.NET v4.0 App Pool neu gestartet und alles hat wieder funktioniert!

Dan,

Versuchen Sie zusätzlich zu Aarons Vorschlägen Folgendes

• Überprüfen Sie, ob die integrierte Windows-Authentifizierung auf Ihrer IIS-Website ausgewählt ist
• Können Sie mit Cassini anstelle von IIS debuggen?

Hatte das gleiche Problem mit Windows 10, wenn alle IIS-Windows-Funktionen aktiviert waren. Wechselt zu Windows 8.1 und hat wieder ein Problem. Das Stammverzeichnis befand sich im Website-Namen " http: //MySite.local " (nicht mit der Betriebssystemversion verwandt).

Und die Lösung ist einfach

• Bearbeiten Sie die Hosts-Datei in %SystemRoot%\System32\drivers\etc\

• Zeile mit IP-Bindung hinzufügen: 127.0.0.1 MySite.local

Ich hatte diesen Fehler heute aufgrund eines Codefehlers, der sehr oft zurückgesendet wurde und dazu führte, dass IIS mit Anforderungen überflutet wurde. Dadurch wurde IIS im Wesentlichen blockiert, und als ich versuchte, das Debugger zu starten, trat beim Versuch, den Debugger zu starten, eine Zeitüberschreitung auf. Ich habe IIS einfach neu gestartet, was einige Minuten gedauert hat, und das Problem wurde behoben.

Ich wünschte, dieser Fehler wäre weniger allgemein, es scheint, als gäbe es verschiedene Möglichkeiten, ihn zu erzeugen.

Ich hatte das gleiche Problem in Visual Studio 2012 und 2013 unter Windows 8.1. Für mich bestand die Lösung darin, die Windows-Authentifizierung zu IIS hinzuzufügen, indem Sie die Windows-Funktionen aktivieren oder deaktivieren.

Stellen Sie sicher, dass der Anwendungspool Ihrer Site die richtige Framework-Version verwendet . Auf einer ASP.Net 2005-Site wurde der Fehler "Debugging kann nicht gestartet werden" angezeigt. Es wurde fälschlicherweise der DefaultAppPool unter Windows 7 verwendet (von dem ich glaube, dass er .Net Framework 4 verwendet). Ich habe einen neuen App-Pool basierend auf .Net Framework 2 erstellt und ihn der Problemwebsite zugewiesen. Danach hat das Debuggen gut funktioniert.

Überprüfen Sie, ob Ihre Website auf IIS nicht gestoppt wird.

Ich habe das Problem behoben, durch das meine Website ausgeführt wurde. : D.

Ich hatte dieses Problem und stellte schließlich fest, dass I ASP.net nicht ordnungsgemäß bei IIS registriert ist. Dies kann passieren, wenn der IIS-Server vor Visual Studio installiert wird. Verwenden Sie den Befehl aspnet_regiis -i, um dieses Problem zu beheben. Weitere Informationen finden Sie unter dem Link

hatte das gleiche Problem. Wenn Sie ein SSL-Zertifikat auf IIS installiert haben und versuchen, es in Visual Studio zu debuggen, müssen Sie Ihre Anwendung auf IIS so einstellen, dass das Zertifikat ignoriert wird.

Ich hatte das gleiche Problem und stellte fest, dass es verursacht wurde, weil ich ein Zeichen falsch in mein Web.configAfter-the-End-Tag eingegeben hatte . Mein Web.configsah aus wie dieses Recht am Ende: </section>h. Das "h" war ein zusätzliches Zeichen nach dem schließenden Tag.

Entfernen Sie den Stich wie folgt: targetFramework = "4.0" in web.config oder ändern Sie AppPool in die entsprechende Framework-Version.

Die Deinstallation der IIS UrlScan-Erweiterung hat das Problem für mich gelöst.

Ich hatte das gleiche Problem, aber es befand sich auf dem eigenen Webentwicklungsserver von Visual Studios anstelle von IIS. Um das Problem zu umgehen, deaktivieren Sie die Option auf der Registerkarte "Web" unter "Projekteigenschaften". "Servereinstellungen auf alle Benutzer anwenden (in Projektdatei speichern".) es wird jemandem wertvolle Zeit sparen.

Ich hatte das gleiche Problem. Alle obigen Antworten haben bei mir nicht funktioniert. Die Lösung bestand darin, den Ordner bin und obj manuell zu löschen.

Ich fand dieses Problem auch, aber es war dem, was @Kirk erklärte, und dem Umschreiben der URL am ähnlichsten.

In meinem Fall hatte jemand diese Änderung an der Datei web.config für ein MVC-Projekt eingecheckt:

<system.webServer>
    <security>
        <requestFiltering>
            <fileExtensions>
                <add fileExtension=".aspx" allowed="false" />
            </fileExtensions>
        </requestFiltering>
    </security>
</system.webServer>

Da ASPX-Dateierweiterungen auf dem Webserver nicht zulässig waren, wurde die /debugattach.aspxURL verweigert, sodass der Debugger nicht ausgeführt werden konnte. Nachdem ich diese Konfiguration entfernt hatte, funktionierte sie wieder.

Ich hatte das gleiche Problem, als ich eine Anwendung in Visual Studio erstellte und dann in den Eigenschaften ein virtuelles Verzeichnis zur Verwendung mit lokalem IIS erstellte. Wenn jemand diesen Fehler hat, liegt dies daran, dass VS eine Anwendung unter falschem AppPool erstellt, dh unter AppPool, das nicht Ihren Anforderungen entspricht.
Wenn dies der Fall ist, gehen Sie zum IIS-Manager, wählen Sie App, gehen Sie zu Grundeinstellungen und ändern Sie AppPool für App, und Sie können loslegen.

Ich habe kürzlich denselben Fehler erhalten und in meinem Fall stellte sich heraus, dass es doppelte MIME-Typen gab. Ich hatte kürzlich zwei hinzugefügt, die anfangs nicht in der Liste auftauchten. Mit IIS konnte ich sie hinzufügen. Erst als ich mich entschied, die MIME-Typen für die Site im Rahmen meines Diagnoseprozesses erneut zu überprüfen, trat auch in IIS ein Fehler auf. Es verwies auf Duplikate in web.config. Als ich zurück in die Datei web.config ging, bemerkte ich, dass ein neuer Abschnitt namens aufgerufen wurde, der die beiden kürzlich hinzugefügten MIME-Typen enthielt. Diesen Abschnitt gelöscht und das Leben ist wieder gut! In der Hoffnung, dass dies anderen hilft, die es nicht geschafft haben, das Problem mit einem der anderen Vorschläge zu beheben.