it-swarm.com.de

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

Ich verwende Visual Studio 2010 (als Admin), IIS 7 unter Windows 7 x64 . Ich bin in der Lage, die ASP.NET-Website unter IIS 7 auszuführen, ohne dass das Debuggen einwandfrei ist, aber wann Ich drücke F5 um es zu debuggen, ich bekomme:

Debugging auf dem Webserver kann nicht gestartet werden. ASP.NET-Debugging konnte nicht gestartet werden. Möglicherweise sind weitere Informationen verfügbar, wenn Sie das Projekt ohne Debugging starten.

Leider hilft mir der Hilfe-Link nicht viel und führt zu einem großen Baum.

Ich habe folgendes geprüft:

  • Sicherheitsanforderungen - Ich kann mich nicht erinnern, vorher etwas Besonderes getan zu haben. Der Arbeitsprozess in IIS7 ist w3wp.exe. Wenn es als ASPNET oder NETWORK SERVICE ausgeführt wird, muss ich über Administratorrechte verfügen, um es zu debuggen. Wie erfahre ich, ob ich hier etwas ändern muss?

  • Eigenschaftsseiten für Websites> Startoptionen> Debugger> ASP.NET ist markiert ..__ Benutzerdefinierter Server wird auf die URL der Website gesetzt (die auch ohne Debugging funktioniert).

  • Das Debuggen ist in web.config aktiviert.

  • Die Anwendung verwendet ASP.NET 3.5 (ich möchte schließlich auf 4.0 umsteigen, aber ich muss mich mit der Migration befassen).

  • Anwendungspool: .NET AppPool klassifizieren (hat auch DefaultAppPool versucht).

Irgendwelche Ideen, wo ich als nächstes nachschauen 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.

92
Dan C

Es stellt sich heraus, dass der Täter das Modul IIS Url Rewrite war. Ich hatte eine Regel definiert, die Anrufe an Default.aspx (die als Startseite der Website festgelegt wurde ) an den Stamm der Site umgeleitet hat, sodass ich eine kanonische Heimat-URL verwenden konnte. Anscheinend hatte VS jedoch ein Problem und wurde verwirrt. Dieses Problem ist nicht aufgetreten, als ich Helicon ISAPI_Rewrite verwendet habe.

Am Ende habe ich eine völlig neue Website erstellt und Projekte/Dateien nach und nach in meine Lösung eingefügt und meine web.config neu erstellt, bis ich das herausgefunden habe! Nun, jetzt habe ich eine etwas sauberere Seite .NET 4.0 (hoffentlich stoße ich nicht in Wände) - aber was für ein Schmerz!

44
Dan C

Gehen Sie zu IIS und überprüfen Sie, ob der von Ihnen verwendete App Pool gestartet ist. In vielen Fällen wird ein Fehler angezeigt, der den App-Pool herunterfährt. Sie müssen nur mit der rechten Maustaste und Start klicken, und Sie sollten gut sein.

238
Trey Copeland

Beim Starten von Visual Studio wird (aus irgendeinem Grund) versucht, auf die URL zuzugreifen:

/debugattach.aspx

Wenn Sie eine Umschreibregel haben, die umleitet (oder auf andere Weise abfängt), beispielsweise .aspx-Dateien, werden Sie an einer anderen Stelle diese Fehlermeldung erhalten. Die Lösung besteht darin, diesen Abschnitt am Anfang des web.config-Abschnitts Ihres <system.webServer>/<rewrite>/<rules> hinzuzufügen:

<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 bestimmte Anforderung abgefangen wird, do nothing und vor allem die Ausführung angehalten werden, damit keine Ihrer anderen Regeln ausgeführt wird. Dies ist eine robuste Lösung, die Sie für die Produktion in Ihrer Konfigurationsdatei aufbewahren können.

40
Kirk Woll

Zum Vorteil anderer habe ich in meinem Fall den Anwendungspool so konfiguriert, dass er meine Windows-Anmeldeinformationen verwendet, um auf eine Netzwerkressourcenfreigabe zuzugreifen. Seit dem letzten Debuggen der Lösung hatte ich mein Windows-Kennwort zurückgesetzt. Das geänderte Passwort wurde im App-Pool und im bada bing gespeichert.

30
Breeno

Wenn für ApplicationPool Identity ein benutzerdefiniertes Konto festgelegt und das Kennwort des Computers geändert wird, müssen Sie Ihr Kennwort aktualisieren

19
Hello World

Für mein Szenario wurden Änderungen am Abschnitt httpErrors in der Datei web.config vorgenommen.

<httpErrors mode="Custom"> 

hat das Problem "Debuggen auf dem Webserver kann nicht gestartet werden" verursacht. Durch das Zurücksetzen auf den vorherigen Wert von "DetailedLocalOnly" wurde das Problem behoben. Beim tieferen Graben habe ich herausgefunden, dass es nur die 401-Fehlereinstellung war, die dies verursachte:

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

Durch das Auskommentieren der 401-Fehlerzeile wurde das Problem ebenfalls behoben. Ich bin damit einverstanden, da ich dann die benutzerdefinierte Fehlerbehandlung beibehalten und mit dem Debuggen beginnen kann.

Ich habe immer noch keine Ahnung, warum das so ist.

17

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

13
user3206598

Hatte das gleiche Problem beim Versuch, ein DNN (Dot Net Nuke) -Modul zu debuggen

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

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

11
Zar Shardan

Ich habe genau das gleiche Problem, nachdem ich das Überschreibungsmodul implementiert habe.

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

Um dies zu umgehen, kommentiere ich die Umschreibungs-Tags beim Debuggen einfach aus, wie hier ...

<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.

8
geofili

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

6
Ovini

So habe ich den von Ihnen festgestellten Fehler behoben. Suchen Sie den Webordner für die App im Dateisystem, wechseln Sie zu Properties => Security, klicken Sie auf die Schaltfläche Advanced, klicken Sie auf die Registerkarte Owner, klicken Sie auf die Schaltfläche Edit und ändern Sie die Einstellung den Eigentümer (mit den richtigen Berechtigungen) des Ordners und das Kontrollkästchen "Besitzer auf Untercontainern und Objekten neu festlegen"] aktiviert. Klicken Sie auf "Apply" und dann war ich im Geschäft (konnte debuggen).

Hoffe das klappt für jemand anderen. 

5
Moe Howard

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

5
Todd Vance

Wenn der App Pool Probleme hat, neu zu starten oder einfach nicht neu gestartet werden soll, überprüfen Sie, ob Windows kürzlich ASP.NET v4.0 oder einen anderen App Pool aktualisiert hat. Das ist in meinem Fall passiert. Ich habe einfach meinen Computer neu gestartet, dann den App.Pool von ASP.NET v4.0 neu gestartet und alles funktionierte wieder!

3
Chewbacca17

Ich habe dieselbe Fehlermeldung in VS 2012 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

3
Tom Gerken

Dan,

Versuchen Sie zusätzlich zu den Vorschlägen von Aaron Folgendes

  • Vergewissern Sie sich, dass die integrierte Windows-Authentifizierung auf Ihrer IIS Website ausgewählt ist
  • Können Sie mit Cassini anstelle von IIS debuggen?
2
Keefu

Hatte dasselbe Problem mit Windows 10, wenn alle IIS Windows-Funktionen aktiviert waren. Umstellung auf Windows 8.1 und Problem erneut. Das Stammverzeichnis befand sich im Website-Namen " http: //MySite.local " (nicht mit der Betriebssystemversion verbunden). 

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

2
Artru

Prüfen Sie, ob Ihre Website auf IIS nicht angehalten ist. 

Ich habe es behoben und meine Website zum Laufen gebracht. : D

1
AFetter

Stellen Sie sicher, dass der Anwendungspool Ihrer Site die richtige Framework-Version verwendet . Ich habe auf einer ASP.Net 2005-Site den Fehler "Debuggen kann nicht beginnen" angezeigt. Es wurde fälschlicherweise der DefaultAppPool unter Windows 7 (der .Net Framework 4 verwendet wurde) verwendet. Ich habe einen neuen App-Pool basierend auf .Net Framework 2 erstellt und der Problem-Website zugewiesen. Danach funktionierte das Debuggen gut.

1
DeveloperDan

hatte das gleiche Problem. Wenn auf IIS ein SSL-Zertifikat installiert ist und Sie versuchen, es von Visual Studio aus zu debuggen, müssen Sie Ihre Anwendung auf IIS setzen, um das Zertifikat zu ignorieren. 

1
akd

Ich hatte dieses Problem und merkte schließlich, dass ich ASP.net nicht richtig bei IIS registriert habe. Dies kann vorkommen, wenn der IIS -Server vor Visual Studio installiert wird. Um dieses Problem zu beheben, verwenden Sie den Befehl aspnet_regiis -i Weitere Informationen finden Sie im link

1
karpanai

Ich hatte das gleiche Problem in Visual Studio 2012 und 2013 unter Windows 8.1. Für mich bestand das Problem darin, die Windows-Authentifizierung unter Verwendung von 'Windows-Funktionen ein- oder ausschalten' zu IIS hinzuzufügen.

Turn Windows features on or off screenshot

1
dumbledad

Ich hatte das gleiche Problem und stellte fest, dass es daran lag, dass ein Zeichen versehentlich in mein Web.config nach dem Endtag eingegeben wurde. Mein Web.config sah am Ende so aus: </section>h. Das "h" war ein zusätzliches Zeichen nach dem schließenden Tag. 

1
Lavanya

Ich hatte diesen Fehler heute aufgrund eines Codefehlers, der eine ungeheure Anzahl von Zeiten zurückschickte, was dazu führte, dass IIS mit Anforderungen überschwemmt wurde. Dies war im Wesentlichen blockiert IIS. Beim Debuggen wurde also ein Zeitlimit überschritten, als der Debugger gestartet werden sollte. Ich habe IIS einfach neu gestartet, was einige Minuten dauerte, und das Problem wurde gelöst.

Ich wünsche mir zwar, dass dieser Fehler weniger generisch wäre, es scheint verschiedene Wege zu geben, um ihn zu erzeugen.

1
ammills01

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

0
Willow

Durch die Deinstallation der IIS UrlScan-Erweiterung wurde das Problem für mich gelöst.

0
Thomas

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

In meinem Fall hatte jemand diese Änderung in 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.aspx-URL abgelehnt, wodurch der Debugger nicht ausgeführt werden konnte. Nachdem ich diese Konfiguration entfernt hatte, funktionierte es wieder.

0
Peter Monks

Ich habe diesen Fehler kürzlich 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 aufgeführt waren. IIS Lassen Sie mich diese hinzufügen, und erst als ich beschloss, die MIME-Typen für die Site im Rahmen meines Diagnoseprozesses erneut zu überprüfen, erhielt ich auch einen Fehler in IIS. In web.config wurde auf Duplikate verwiesen. Nachdem ich in die Datei web.config zurückgekehrt war, fiel mir auf, dass ein neuer Abschnitt mit dem Namen "MIME" hinzugefügt wurde, der die beiden kürzlich hinzugefügten MIME-Typen enthielt. Diesen Abschnitt gelöscht und das Leben ist wieder gut! Wenn Sie hoffen, dass dies anderen helfen kann, die es noch nicht geschafft haben, das Problem mit einem der anderen Vorschläge zu beheben?.

0
Mike

Ich war mit dem gleichen Problem konfrontiert, aber es befand sich auf einem eigenen Web-Entwicklungsserver von Visual Studios anstelle von IIS. Um die Option zu deaktivieren, deaktivieren Sie die Option auf der Registerkarte "Web" unter den Projekteigenschaften es wird einige wertvolle Zeit sparen.

0
user3169006

Ich hatte das gleiche Problem. Alle oben genannten Antworten funktionierten nicht für mich. Die Lösung bestand darin, den Ordner bin und obj manuell zu löschen.

0
user1949096

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

0
Slava