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

92

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.

Dan C.
quelle
1
Um klar zu sein, als Sie Visual Studio gestartet haben, haben Sie mit der rechten Maustaste darauf geklickt und die Option Als Administrator ausführen ausgewählt.
Aaron Carlson
Hast du diesen Link schon ausgecheckt? msdn.microsoft.com/en-us/library/dwesw3ee.aspx
Aaron Carlson
@ Aaron, Ja, ich habe VS so eingestellt, dass es immer als Administrator ausgeführt wird.
Dan C
@ Aaron, ich habe diese Seite und ihre Kinder explizit durchgesehen, bevor ich hier gepostet habe, und nichts ist aufgefallen, was ich tun musste. Mein System erfüllt die Anforderungen und das Debuggen ist für die Site aktiviert. Ich habe Windows Server 2003 nicht, daher wird dort kein IIS konfiguriert. Ich habe keine Sicherheitseinstellungen für irgendetwas berührt, da ich nicht weiß, ob ich muss.
Dan C
Ich bin mir nicht sicher, ob dies hilft, aber ich habe versucht, eine neue Test-ASP.NET 3.5-Website in VS 2010 zu erstellen, sie ohne spezielle Konfigurationen zu IIS 7 hinzugefügt und konnte sie problemlos debuggen. Etwas mit meiner Hauptanwendung, wie sie in VS, IIS oder vielleicht sogar im Dateisystem konfiguriert ist. Nur nicht sicher, wo ich anfangen soll zu suchen.
Dan C

Antworten:

239

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.

Trey Copeland
quelle
Danke, wünschte ich hätte diesen Beitrag Freitag gefunden! Der Pool war gestoppt und ich stoße auf den ersten Fehler
Christopher Cabezudo Rodriguez
In meinem Fall musste ich ASP.NET v4.0.30319 in ISAPI- und CGI-Einschränkungen zulassen
Adi
15
+1 Ungültiger Benutzername / Passwort zur Authentifizierung des App-Pools.
P.Brian.Mackey
3
In meinem Fall wurde der Pool bereits gestartet, aber nach dem Stoppen und erneuten Starten hat es funktioniert.
Serj Sagan
1
Vielen Dank. Diese Lösung hat bei mir perfekt funktioniert. Ich musste den Anwendungspool zusätzlich neu starten.
Sunil
44

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!

Dan C.
quelle
6
Ja, aber Sie müssen sicher sein, dass der Anwendungspool ausgeführt wird, auch Ihr Portal.
Junior Mayhé
In diesem Sinne war mein Problem in der web.config unter: <applicationInitialization remapManagedRequestsTo = "/ App / splash.html" doAppInitAfterRestart = "true" lockAttributes = ""> <add initializationPage = "App / index.html" hostName = " CSI "lockItem =" true "/> </ applicationInitialization>. Ich habe das verwendet, um einen Begrüßungsbildschirm anzuzeigen, während die Anwendung initialisiert wurde.
Nick
6
Das war es für mich. Die Umschreiberegel zum Senden des gesamten HTTP-Verkehrs an HTTPS verursachte diesen hässlichen Fehler. Ich konnte keine Möglichkeit finden, die Regel für das Debuggen beizubehalten.
Kat
Ich wollte nur hinzufügen, dass es für mich ähnlich war, aber das SSL-Umschreiben, das wir gemeint hatten, war, dass unser Startpfad localhost / appname war, aber als die Umleitung Sie zu localhost / appname schickte , verursachte VS einen Fehler, da es die Umleitung nicht verarbeiten kann. Wir haben eine Stunde gebraucht, um dieses Problem zu finden, da beim Testen in IIS vor Ort alles perfekt funktioniert hat!
Liam Wheldon
Gleiches Problem hier (IIS Url Rewrite-Modul). Ich löse es, indem ich meine Regeln auf meine verschiebe Web.Release.config. Siehe weblogs.asp.net/srkirkland/… und stackoverflow.com/questions/11032868/… .
Swisher Sweet
42

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.

Kirk Woll
quelle
1
Dies hat bei mir persönlich leider nicht funktioniert, aber ich kann überprüfen, ob es sich definitiv um ein Problem beim Umschreiben handelt, da ich den Abschnitt zum Umschreiben von web.config auskommentiert habe und ohne Probleme ausgeführt werden kann.
Matt
Vielleicht möchten Sie die Lösung von hier aus ausprobieren : stackoverflow.com/a/30813200/375303 . Funktioniert wie ein Zauber für mich.
jerhewet
Visual Studio protokolliert hier Fehler in Bezug auf DebugAttach.aspx:% UserProfile% \ AppData \ Local \ Temp \ Visual Studio Web Debugger.log (Wenn Sie diese Datei nicht haben - oder wenn es sich um eine alte Datei handelt - dann Ihr Problem ist wahrscheinlich nicht mit DebugAttach.aspx verwandt.)
Brandon S
In meinem Fall ist die Grundursache korrekt, aber nicht die Lösung. Für mich hat das funktioniert: <location path="debugattach.aspx"> <system.webServer> <validation validateIntegratedModeConfiguration="false" /> <httpErrors errorMode="DetailedLocalOnly" existingResponse="PassThrough"> <clear /> </httpErrors> </system.webServer> </location>
Tasos K.
Für mich lag das Problem an "/debugattach.aspx", aber die Lösung bestand darin, erroMode auch in "DetailedLocalOnly" zu ändern.
Nashe
30

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.

Breeno
quelle
Vielen Dank dafür, dass ich nicht einmal eine Netzwerkfreigabe verwendet habe, aber das hat großartig funktioniert.
Marissa
21

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

Hallo Welt
quelle
Ja, hatte ein Problem, versuchte ein paar Antworten von hier ohne Ergebnis, Ihre Antwort hat mir wirklich geholfen!
Vadzim Savenok
19

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.

Fjarskiptagervitungl
quelle
Die gleiche Ursache für mich war, dass beim Versuch, mit dem Debuggen zu beginnen, 401 Antworten in meinen Protokollen aufgetreten sind. Durch Deaktivieren meiner Standardfehlerbehandlung wurde das Problem "vs kann nicht debuggen" für mich behoben. Ich verstehe nicht, warum 401 auch auf meiner Anmeldeseite auftritt, wenn und nur wenn das Debuggen mit vs gestartet wird, während nur anonymer Zugriff und Webformularauthentifizierung erfolgen. aktiviert sind.
Frédéric
Dies war auch das Update für mich, nur ich habe einen Standardfehlerpfad festgelegt, anstatt explizit einen für 401 zu definieren.
Dienstag,
Dies hat bei mir funktioniert (ich habe vorübergehend den gesamten httperrors-Bereich entfernt). Die Dinge, die ich zuvor versucht habe und die nicht funktionierten, waren das Neustarten des App-Pools und das Entfernen von Regeln zum Umschreiben von URLs.
Nicholas Westby
Das hat bei mir funktioniert. dann habe ich meinen benutzerdefinierten Fehler geändert, als @Pablo Romeo in dieser Antwort schrieb: stackoverflow.com/a/13905859/4489664
Bondaryuk Vladimir
2
Das Ändern von erroMode in "DetailedLocalOnly" wurde auch für mich gelöst. Der Debugger hat versucht, "/DebugAttach.aspx" zu öffnen, wodurch die benutzerdefinierte Fehlerseite aufgerufen wurde, die zum angegebenen Zeitpunkt nicht ausgeführt werden konnte.
Nashe
13

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

user3206598
quelle
4
Dies entspricht der Antwort Nummer 1, die einen Monat zuvor vorgeschlagen wurde.
Mac10688
OK, das ist es, aber warum hört es jedes Mal auf?
Fernando Torres
Mein Anwendungspool wurde auf einem Benutzer ausgeführt, dessen Kennwort geändert wurde.
Anderson
11

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

Zar Shardan
quelle
Danke dir!! Ich habe mir den ganzen Tag die Haare ausgerissen und die Lösung war so einfach. Wenn nur VS eine aussagekräftige Fehlermeldung geben könnte!
Colincameron
8

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.

Geofili
quelle
1
Es ist zwar eine Problemumgehung, aber eine schlechte, da man leicht vergisst, solche Kommentare vor dem Festschreiben oder Veröffentlichen der Website zu entfernen.
Jon Adams
1
Sie können diese Zeilen in die Konfigurationsdatei web.config.release verschieben. Wenn Sie sie veröffentlichen, wird sie nur in der veröffentlichten Version angezeigt. Das ist, was ich tat.
Shalke
Vielleicht reicht es aus, nur /debugattach.aspx auszuschließen. Schauen Sie sich Peter Monks Kommentar an
Daniel Fisher lennybacon
6

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

Ovini
quelle
Mein Problem wurde auch gelöst! Ich habe festgestellt, dass mein DefaultAppPool gestoppt wurde. Vielen Dank für das Teilen. Ich kann nicht verstehen, warum es aufgehört hat.
Jobert Enamno
5

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.

Moe Howard
quelle
2
Wechseln Sie den Besitzer zu wem?
Dumbledad
5

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!

Todd Vance
quelle
3

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

Tom Gerken
quelle
3

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!

Chewbacca17
quelle
2

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?
Keefu
quelle
Ich habe die folgenden Schritte ausgeführt, um die integrierte Windows-Authentifizierung zu aktivieren : msdn.microsoft.com/en-us/library/x8a5axew.aspx Ich habe jedoch immer noch den gleichen Fehler (iis manager zeigt die Warnung an, dass ich nicht sowohl die Herausforderung als auch die anmeldebasierte Authentifizierung verwenden kann - Meine Website verwendet die Formularauthentifizierung. Ich kann eine Site mit dem in VS 2010 integrierten Webserver debuggen, aber es fehlen Funktionen.
Dan C
Haben Sie versucht, eine neue Website in IIS zu erstellen und Ihren Code dort bereitzustellen? Welche Funktionen würden Sie aus Neugier vermissen, wenn Sie in Cassini debuggen würden? Meines Wissens unterstützt Cassini die Formularauthentifizierung.
Keefu
Was meinen Sie mit "Erstellen einer neuen Website in IIS"? Dies ist ein neuer Computer mit einem neuen Betriebssystem, VS2010, IIS-Installationen. Ich habe eine neue Anwendung in IIS erstellt und auf den Ordner der tatsächlichen Website verwiesen (aus einer Sicherung abgerufen). URL Rewrite scheint in Cassini nicht vollständig zu funktionieren. Außerdem verwenden wir ein benutzerdefiniertes Modul, um automatisch zwischen http und https zu wechseln ( codeproject.com/KB/web-security/WebPageSecurity_v2.aspx ).
Dan C
Cassini unterstützt das Url Rewrite 2 Modul
citronas
2

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

Artru
quelle
Dies war ein Juwel für mich, ich habe das Einrichten meiner Host-Datei völlig vergessen und mich gefragt, warum meine Apis nicht funktionierten, als ich auf lokales iis (für https) umgestellt habe. VS arbeitete nur mit einer Site, die darin ausgeführt wurde, aber nachdem ich eine zweite hinzugefügt hatte, konnte ich nicht mehr debuggen, dies löste das Problem.
CDerrig
1

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.

ammills01
quelle
1

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.

Aktivieren oder deaktivieren Sie den Windows-Screenshot

Dumbledad
quelle
1

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.

DeveloperDan
quelle
1

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

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

AFetter
quelle
1

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

Karpanai
quelle
1

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.

akd
quelle
1

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.

Lavanya
quelle
0

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

Slava
quelle
0

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

Thomas
quelle
0

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.

user3169006
quelle
0

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.

user1949096
quelle
0

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.

Peter Monks
quelle
0

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.

Weide
quelle
0

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.

Mike
quelle