variable Das Debugging auf dem Webserver kann nicht gestartet werden. Das Debuggen von ASP.NET VS 2010, II7, Win 7 x64 konnte nicht gestartet werden



visual studio code vbscript debugging (24)

Dan,

Versuchen Sie zusätzlich zu Aarons Vorschlägen Folgendes

  • Stellen Sie sicher, dass auf Ihrer IIS-Website die integrierte Windows-Authentifizierung ausgewählt ist
  • Können Sie Cassini anstelle von IIS debuggen?

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

Das Debugging auf dem Webserver kann nicht gestartet werden. Das Debugging von ASP.NET konnte nicht gestartet werden. Weitere Informationen können verfügbar sein, indem das Projekt ohne Debugging gestartet wird.

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

Ich habe Folgendes überprüft:

  • Sicherheitsanforderungen - Ich kann mich nicht erinnern, vorher etwas Besonderes gemacht zu haben. Der Arbeitsprozess in IIS7 ist w3wp.exe. Es besagt, dass, wenn es als ASPNET oder NETWORK SERVICE ausgeführt wird, ich Administratorrechte haben muss, um es zu debuggen. Wie finde ich heraus, ob ich hier etwas ändern muss?

  • Website-Eigenschaftsseiten> Startoptionen> Debugger> ASP.NET ist aktiviert. Verwenden Sie den benutzerdefinierten Server als URL der Site (was ohne Debugging funktioniert).

  • Das Debuggen ist in web.config .

  • Die Anwendung verwendet ASP.NET 3.5 (Ich möchte eventuell zu 4.0 wechseln, habe aber eine Migration zu bewältigen).

  • Anwendungspool: Classing .NET AppPool (auch versucht DefaultAppPool).

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

Sicherlich sollte es nicht so schwer sein, IIS, VS zu installieren, eine Website zu erstellen und zu testen?

Danke im Voraus.


Answer #1

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


Answer #2

Ich habe dieses Problem ebenfalls gefunden, aber es ähnelt dem, was @Kirk erklärt hat und URL-Rewriting.

In meinem Fall hatte jemand diese Änderung in die 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 URL /debugattach.aspx verweigert, /debugattach.aspx der Debugger nicht ausgeführt werden konnte. Sobald ich diese Konfiguration entfernt habe, hat es wieder funktioniert.


Answer #3

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


Answer #4

Hatte das gleiche Problem mit Windows 10, wenn alle IIS-Windows-Funktionen aktiviert waren. Switched zu Windows 8.1 und bekam wieder ein Problem. Das Stammverzeichnis war im Websitenamen " 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 127.0.0.1 MySite.local : 127.0.0.1 MySite.local


Answer #5

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


Answer #6

Ich hatte das gleiche Problem und festgestellt, dass es verursacht wurde, weil ich ein Zeichen versehentlich in meine Web.config nach dem End-Tag getippt hatte. Meine Web.config sah am Ende so aus: </section>h Web.config </section>h . Das "h" war ein zusätzliches Zeichen nach dem schließenden Tag.


Answer #7

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


Answer #8

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


Answer #9

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


Answer #10

Durch das Deinstallieren der IIS-UrlScan-Erweiterung wurde das Problem für mich behoben.


Answer #11

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

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

Um das zu umgehen, muss ich nur die Tags beim Debuggen auskommentieren, so ...

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


Answer #12

Stellt sich heraus, dass der Täter 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 Site umleitete, so dass ich eine kanonische Home-URL haben konnte. Offensichtlich hatte VS jedoch ein Problem damit und wurde verwirrt. Dieses Problem trat nicht auf, als ich Helicon ISAPI_Rewrite verwendete, so dass es mir nicht einmal einfiel, das zu überprüfen.

Ich habe 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! Naja, zumindest jetzt habe ich mit .NET 4.0 eine etwas sauberere Seite (soweit ich hoffentlich keine Wände renne) - aber was für ein Schmerz!


Answer #13

Hatte das gleiche Problem versucht, ein DNN (Dot Net Nuke) -Modul zu debuggen. Es stellte sich heraus, dass Sie die Kompilierung debug = "true" haben müssen:

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

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


Answer #14

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


Answer #15

Ich habe diesen Fehler kürzlich bekommen 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. IIS ließ mich sie hinzufügen, und nur als ich mich entschied, die MIME-Typen für die Site erneut als Teil meines Diagnoseprozesses zu überprüfen, habe ich einen Fehler in IIS außerdem erhalten. Es referenzierte Duplikate in web.config. Als ich wieder in die web.config-Datei ging, bemerkte ich, dass ein neuer Abschnitt namens "hinzugefügt" hinzugefügt wurde, der die zwei kürzlich hinzugefügten MIME-Typen enthielt. Habe diesen Abschnitt gelöscht und das Leben ist wieder gut! In der Hoffnung, dies könnte anderen helfen, die es nicht geschafft haben, das Problem mit einem der anderen Vorschläge zu beheben.


Answer #16

Ich hatte diesen Fehler heute wegen eines Defekts im Code, der eine enorme Menge von Zeiten, die IIS mit Anfragen überschwemmt verursachen. Dies schloss im Wesentlichen IIS und so, wenn ich versuchte zu debuggen, es 'Zeitüberschreitung' versucht, den Debugger zu starten. Ich habe IIS einfach neu gestartet, was einige Minuten dauerte und das Problem gelöst hat.

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


Answer #17

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

Ich habe es behoben, meine Website zum Laufen zu bringen. : D


Answer #18

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

/debugattach.aspx

Wenn Sie eine Rewrite-Regel haben, die .aspx Dateien an anderer Stelle .aspx (oder auf andere Weise .aspx ), erhalten Sie diesen Fehler. Die Lösung besteht darin, diesen Abschnitt am Anfang des web.config <system.webServer>/<rewrite>/<rules> von web.config <system.webServer>/<rewrite>/<rules> :

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


Answer #19

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


Answer #20

hatte dasselbe Problem. Wenn Sie ein SSL-Zertifikat auf IIS installiert haben und wenn Sie versuchen, es aus Visual Studio zu debuggen, müssen Sie Ihre Anwendung auf IIS festlegen, um das Zertifikat zu ignorieren.


Answer #21

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


Answer #22

Ich hatte das gleiche Problem, aber es war auf Visual Studios eigenen Web-Entwicklungsserver anstelle von IIS. Die Umgehung ist, deaktivieren Sie die Option auf der Registerkarte Web unter Projekteigenschaften, Servereinstellungen für alle Benutzer anwenden (in Projektdatei speichern.) es wird einige wertvolle Zeit sparen.


Answer #23

Ich hatte dieses Problem und erkannte schließlich, dass ich ASP.net nicht ordnungsgemäß bei IIS registriert wurde. Dies kann passieren, wenn der IIS-Server vor Visual Studio installiert ist. Um dieses Problem zu beheben, verwenden Sie den Befehl aspnet_regiis -i Weitere Informationen finden Sie in der link





visual-studio-debugging