Das Visual Studio 2015-Projekt wird nicht mehr im Debug-Modus ausgeführt

Folgendes bekomme ich auch, wenn ich in der Debug-Konfiguration ausgeführt werde:

Ich habe dies gezeigt, indem ich "Nur mein Code" aktiviert und gewarnt habe, wenn beim Start kein Benutzercode vorhanden ist. Dies ist etwas, das kürzlich mit unserem Projekt passiert ist, und ich bin mir nicht sicher, was wir getan haben, um dies zu verursachen. Aber ich konnte es nicht reparieren. Haltepunkte werden nicht ausgelöst und die schnelle Überwachung liefert seltsame Ergebnisse.

Ich habe versucht, das Problem zu googeln, aber keine der Standardlösungen "Haltepunkte werden nicht ausgelöst" hat funktioniert. Ich habe keine Ideen mehr.

Ich habe den Konfigurationsmanager überprüft und jedes Projekt ist dort auch auf Debug eingestellt.

Ich habe "Optimaisierungen aktivieren" deaktiviert und erhalte nicht mehr das Dialogfeld "Sie debuggen einen Release-Build". Es läuft und stoppt wieder an Haltepunkten! Das Ausgabefenster zeigt dies jedoch beim Start an:

Symbole für das Modul 'Navigo.exe' wurden nicht geladen.

1. Verwenden Sie eine Debug-Build-Konfiguration oder deaktivieren Sie die Debug-Option "Nur meinen Code aktivieren".
2. Überprüfen Sie die Einstellungen für 'Symbole' unter Debugging-Optionen.

So löst dies mein primäres Problem der nicht mehr in der Lage zu sein Stützpunkte und das Popup zu verwenden. Was seltsam ist, da ich dachte, Sie müssten Symbole laden, damit Haltepunkte funktionieren. Wie können die Haltepunkte funktionieren, wenn die Symbole nicht geladen sind? Vielleicht ist es nur eine schlechte Nachricht?

Verwenden Sie den Konfigurationsmanager, um die tatsächlichen Einstellungen für die Debug-Konfiguration zu überprüfen. Diese finden Sie im Menü Erstellen → Konfigurationsmanager ..., falls sie Release verwenden :

Stellen Sie außerdem sicher, dass das Projekt DEBUG korrekt definiert und "Code optimieren" nicht aktiviert ist:

Das ist mir auch bei einigen Projekten passiert. Ich habe meine Build-Einstellungen überprüft, wie von stuartd vorgeschlagen . In meinen Build-Einstellungen war "Code optimieren" jedoch nicht aktiviert. Also habe ich es aktiviert und das Projekt gespeichert. Dann habe ich es deaktiviert und wieder gespeichert. Problem gelöst.

Es gibt eine Art Fehler, der dazu führt, dass das --optimize+Flag an den Debugger übergeben wird. Das Aktivieren und anschließende Deaktivieren ist eine einfache Problemumgehung, bis der Fehler behoben ist.

Dies passierte mir nach dem Anwenden von Update 1. Bestehende Projekte zeigten dies und ich kann es mit einem brandneuen Projekt replizieren. Die gesamte Konfiguration ist auf DEBUG eingestellt, und Optimieren ist nicht aktiviert.

Der Kicker ist, dass das Projekt beim ersten Ausführen (oder nach einer Bereinigung) ohne Meldung einwandfrei ausgeführt wird. Wenn Sie das Projekt anhalten und dann erneut ausführen (Hinweis - das Projekt wird nicht neu erstellt ), wird das Dialogfeld angezeigt.

Die einzige Lösung besteht darin, die Option " Nur mein Code" zu deaktivieren - was ein Hack zu sein scheint, wie es vor Update 1 ohne Probleme der Fall war.

Wenn keine der genannten Lösungen geholfen hat, überprüfen Sie die AssemblyInfo.cs Ihres Projekts auf explizite DebuggableAttribute-Anwendungen. Es scheint, als würde es die Debug- / Release-Optionen des Compilers überschreiben.

Ich hatte diese Zeile in der Datei in meinem Fall (Legacy-Projekt, keine Ahnung, wie es dort ankam). Das Löschen löste das Problem:

[assembly: System.Diagnostics.Debuggable(System.Diagnostics.DebuggableAttribute.DebuggingModes.IgnoreSymbolStoreSequencePoints)]

Wählen Sie das Menü Debug → Optionen und deaktivieren Sie die Option JIT-Optimierung unterdrücken . Für mich geht das.

Quelle: https://connect.microsoft.com/VisualStudio/feedback/details/2116788/flag-optimize-is-passed-to-the-debugger-even-while-the-build-settings-optimize-code-is- Nicht-aktiviert-auf-MVC-C-Web-Projekten-wenn-nur-mein-Code verwendet

Ich bin auch auf dieses Problem gestoßen. Die Lösung bestand darin, meine Projekte einfach zu bereinigen ( Build > Clean Solution) und neu zu erstellen ( Build > Rebuild Solution).

Keine der vorherigen Antworten hat bei mir funktioniert. Durch einen Neustart von IIS wurde das Problem behoben.

Fügen Sie einfach eine Randnotiz zu stuartds Antwort hinzu :

Stellen Sie sicher, dass Sie alle abhängigen Projekte auf dieselben Build-Einstellungen überprüfen. Sie erhalten dieselbe Meldung, wenn Ihr Hauptprojekt über die richtigen Einstellungen verfügt, Ihre abhängigen Projekte jedoch nicht. Im Nachhinein macht es offensichtlich Sinn, aber es war nicht das erste, was mir in den Sinn kam.

In meinem Fall bestand das Problem darin, dass die IIS- Projekt-URL in der Webregisterkarte mit den ASP.NET-Projekteigenschaften auf die falsche URL festgelegt wurde.

Es zeigte auf http: // localhost, das ich mit einer anderen Kopie des Projekts verwendete. Die Adresse für die Lösung, die ich geöffnet hatte, wurde auf meinem lokalen IIS tatsächlich als http: // localhost: 90 konfiguriert .

Das Ändern der richtigen Adresse hat das Problem behoben.

Ich habe so ziemlich alles in dieser Liste ausprobiert, aber am Ende habe ich dies behoben, indem ich die Lösungseigenschaften geöffnet und von "Mehrere Startprojekte" zu "Einzelstartprojekt" und wieder zurück gewechselt habe.

1. Klicken Sie mit der rechten Maustaste auf die Lösung und wählen Sie "Eigenschaften".
2. Ändern Sie unter "Allgemeine Eigenschaften" die Auswahl "Mehrere Startprojekte" in "Einzelstartprojekt".
3. OK klicken
4. Führen Sie das Debuggen aus
5. Beenden Sie das Debuggen und wiederholen Sie die Schritte 1 bis 3, wechseln Sie jedoch wieder zu "Mehrere Startprojekte".
6. Führen Sie das Debuggen mit mehreren Projekten erneut aus

Ich hatte das gleiche Problem ... Egal was ich tat - nichts funktionierte.

Es war ein neues leeres Projekt, das das Problem war. Am Ende entfernte ich das Projekt und fügte ein neues Projekt hinzu - das neue Projekt musste einen anderen Namen haben ; Wenn ich denselben Namen verwendet habe, ist der Fehler gerade wieder aufgetreten - auch nach einem Neustart, Bereinigen und Wiederherstellen ... Es muss ein Fehler in Visual Studio 2015 sein.

Für mich war es eine NuGet- Referenz von einem privaten NuGet-Server. Ich weiß nicht, wie es kompiliert wurde, aber das Ändern der Referenz in eine Projektreferenz brachte mich über das Problem hinaus.

Ich habe mein Visual Studio 2012 Pro-Projekt in Visual Studio 2015 Express geöffnet und hatte das gleiche Problem.

Ich habe meine Lösungseigenschaften → Konfigurationseigenschaften überprüft und festgestellt, dass ein Projekt auf Release & x86 festgelegt wurde.

Ich habe es wieder in Debug und Any CPU geändert , und die Eingabeaufforderung ist verschwunden.

In meinem Fall habe ich ein VSTO- Plugin für Outlook entwickelt und Outlook hat versehentlich die Release-Version der DLL-Datei geladen , die ich kürzlich beim Testen meines Installationsprogramms installiert habe.

Es sieht so aus, als hätte Visual Studio versucht, diese DLL anstelle der von mir erwarteten Debug-DLL zu verwenden. Das Beheben, welche DLL-Datei von Outlook geladen wird, hat dies für mich behoben.

Kopieren Sie meine andere Antwort von hier .

Wie von @romanoza erwähnt, hat Microsoft den Fehlerbericht mit den folgenden Informationen aktualisiert:

Deaktivieren Sie die Einstellung Debug -> Optionen -> JIT-Optimierung beim Laden des Moduls unterdrücken (nur verwaltet).

Dies ist die Problemumgehung. Sie sagen später weiter:

Wir empfehlen Leuten, die es nicht aktivieren, da das Deaktivieren sowohl die Leistung als auch das Verhalten nur meines Codes in bestimmten Szenarien verbessert.

Zuletzt die Bestätigung:

Es ist ein Fehler, dass es mit dieser aktivierten Einstellung nicht funktioniert, und wir arbeiten an einer Lösung für diese Situation, falls einige Kunden weiterhin mit dieser aktivierten Einstellung debuggen möchten.

Ich bin auf dasselbe Problem gestoßen und habe es schließlich durch Auswahl von "Nur meinen Code deaktivieren und fortfahren" gelöst .

Nur meine Codeeinstellung

Lösungsschritte:

• Wechseln Sie auf der Seite Eigenschaften des betreffenden Projekts zu den Build- Einstellungen .

• Scrollen Sie nach rechts zur Schaltfläche "Erweitert ..." .

• Stellen Sie sicher , „Debug Info:“ ist nicht  gesetzt „none“ .

  Ich empfehle Ihnen, die vollständige Option zu verwenden.

Nachdem jemand den Link von Patrick als Kommentar zu der Frage angesehen hatte , bemerkte er eine Problemumgehung, die darin bestand, die Site in IIS Express zu stoppen . Ich konnte das gleiche Problem verhindern, indem ich genau das tat, nachdem ich den Debugger in Visual Studio gestoppt hatte.

Ich habe mich jedoch eingehender damit befasst und glaube, dass dies auch mit der Einstellung "Bearbeiten und Fortfahren" für den Debugger zusammenhängen könnte. Als ich das im Menü Extras → Optionen ... von Visual Studio deaktivierte , hatte ich das Problem nicht mehr. Aber das würde Sie daran hindern, die Funktion Bearbeiten und Fortfahren zu verwenden. Ich bin mir nicht sicher, ob sich das für Sie lohnt.

Menü Extras → Optionen → Debugger → Bearbeiten und fortfahren (zum Ende der allgemeinen Liste scrollen) → Deaktivieren Sie das Kontrollkästchen Bearbeiten und fortfahren .

Ich habe dies auch plötzlich nach der Installation von Update 1 erlebt, aber es könnte einfach sein, dass ich diese Einstellung überhaupt erst hatte ... Ich bin mir jedoch nicht sicher.

Falls Sie nur ohne weitere Verzögerungen weitermachen müssen, wählen Sie die letzte Option aus dem Popup aus und alle werden wie zuvor ausgeführt.

Dies war eine seltsame Warnung.

Durch die Neuerstellung der Lösung werden nicht unbedingt alle DLL-Dateien gelöscht (insbesondere diejenigen, die aus abhängigen Projekten kopiert wurden).

Durch die Neuerstellung des Abhängigkeitsprojekts wurde diese Warnung jedoch nicht mehr angezeigt.

Ich habe dies mit Visual Studio 2015 Update 3 konfrontiert.

Meine Lösung war ein bisschen anders als alle anderen und ist ein bisschen einzigartig.

Ich arbeite mit einer Website, die eine Mischung aus verwaltetem Code und ASP Classic enthält , die beide auf dieselbe Assembly verweisen. Visual Studio beschwerte sich, dass meine verwaltete DLL-Datei ein Release-Build war.

Das Problem war eine nicht erfasste Ausnahme in meiner Assembly, wurde jedoch von einer ASP Classic-Seite über Interop ausgelöst. Visual Studio konnte das Debuggen nicht verarbeiten und zeigte die Fehlermeldung an. Dieselbe Ausnahme, die vom verwalteten Code ausgelöst wurde, hätte den Debugger wie erwartet ausgelöst.

Das Korrigieren des Problems im Konstruktor meiner verwalteten Assembly hat alles behoben.

Jetzt, wo ich auf das Gesamtbild zurückblicke, macht alles Sinn, aber zu der Zeit führte mich die Fehlermeldung auf einen sehr tiefen Weg, und ich habe alles in der Antwort hier versucht, bis ich das "Ah-ha!" Moment.

Ich habe zwei Tage verbracht und es sieht so aus, als hätte mir das Zurücksetzen der visuellen Studio 2017-Instanz geholfen.