web-dev-qa-db-de.com

Visual Studio-Haltepunkte unterbrechen die falsche Quelldatei (oder mehrere Dateien gleichzeitig), wenn mehrere Dateien den gleichen Namen haben

In einem Teamprojekt, an dem ich gerade arbeite, führt das Festlegen eines Haltepunkts in einer Datei (z. B. IdeasController.cs) zu unregelmäßigem Verhalten des Debuggers, wenn eine andere Datei mit demselben Namen in der Lösung vorhanden ist. Ich habe das Problem auf mehreren Workstations der Entwickler reproduziert.

Beispiel

Ich habe einen Haltepunkt in IdeasController.cs in unserer Web-API festgelegt:

Breakpoint set in code

Eine weitere Datei mit dem Namen IdeasController.cs ist in unserem separaten MVC 4-Webprojekt vorhanden. In der Abbildung unten zeigt der Debugger den Quellcode Api->IdeasController, die Zeilenmarkierung stimmt jedoch mit der Codestruktur von Web->IdeasController überein. Der Haltepunkt wird dupliziert, wobei sich einer davon mitten in einem Kommentarblock befindet.

Debugger highlight does not match code structure

Das Haltepunktfenster zeigt den Haltepunkt in beiden Dateien gleichzeitig:

Breakpoint spans both files

Auf einigen Arbeitsstationen führt der Debugger die richtigen Zeilen durch (unabhängig von der Zeilenhervorhebung). bei anderen geht es fröhlich durch irrelevante Zeilen (einschließlich Kommentare und Leerzeichen). Ich vermute, das hängt davon ab, welche Quelldatei angezeigt wird.

Was ich versucht habe

Ich habe das Internet durchforstet. Diese Art von Problem scheint aufzutreten, wenn die Debug-Datei (*.pdb), die Quelldatei und der kompilierte Code nicht übereinstimmen. Es gibt viele mögliche Ursachen: Doppelte Dateinamen (die den Debugger verwirren können)[5]), veraltete Projekterstellungsdateien, ungültiger Lösungscache oder falsche Buildkonfiguration.

Dies sind die Lösungen, die ich gefunden und ausprobiert habe:

  • Meine Build-Konfiguration überprüft.
    1. Stellen Sie sicher, dass das Projekt nicht im Freigabemodus erstellt wird.
    2. Es wurde sichergestellt, dass wir keine Code-Optimierung aktiviert haben .
    3. Stellen Sie sicher, dass das Debug-Modul des Projekts korrekt geladen wurde. (Das Debugging des Projekts wurde gestartet und Debug> Windows> Modules überprüft. Beide Assemblys werden aufgelistet, nicht optimiert und haben den Symbolstatus "Geladene Symbole".)
  • Setzen Sie die Metadaten zum Debuggen und den Visual Studio-Cache zurück.
    1. Schließen Sie Visual Studio und löschen Sie die Lösungscachedatei (*.suo).[1]
    2. Die Build-Ausgabe jedes Projekts wurde gelöscht (die Ordner bin und obj). (Zur späteren Bezugnahme: Öffnen Sie den Lösungsordner in Windows Explorer und geben Sie diesen in das Suchfeld ein: "type:folder AND (name:=bin OR name:=obj)").
    3. Der Assembly-Cache-Ordner wurde gelöscht (C:\Documents and Settings\<user>\Local Settings\Application Data\dl3).[2][3]

Keiner von diesen hatte irgendeine Wirkung. Ich kann eine der Dateien umbenennen (ohne die Klasse umzubenennen), um das Problem vorübergehend zu umgehen, aber das ist alles andere als ideal.

Wo ich jetzt bin

Seite 14 meiner neuesten Google-Suche. Vorschläge würden uns sehr freuen. :)

visual-studiodebuggingmsbuildvisual-studio-2012debug-symbols
42
Pathoschild

Ich bin so froh, dass ich diesen Beitrag gefunden habe, dachte ich wäre der einzige und würde verrückt werden! Ich habe das gleiche Problem in VS2012 mit VB.Net und habe alles probiert das OP erwähnt.

Die eindeutige Benennung der Dateien scheint die einzige 100% ige Korrektur zu sein, die ich gefunden habe. Das Deaktivieren aller Haltepunkte, bis die Anwendung geladen ist, und die erforderlichen Haltepunkte wieder aktivieren, funktioniert meistens. Haltepunkte in Lambda-Funktionen können immer noch Probleme verursachen.

6
Miiir

Ich hatte gerade das gleiche Problem. Was für mich gelöst wurde, war das Löschen der .suo-Dateien der Lösung, die die betroffene Projekt-/Quelldatei enthielt.

Ich habe auch meinen lokalen Symbolcache gelöscht, aber ich glaube nicht, dass das etwas damit zu tun hatte.

(Meine Lösung enthält mehrere Projekte, eine Datei (DataAdapter.cs) in einem Projekt war davon betroffen (VisualStudio legte meine Haltepunkte in die pdb, die zu System.Data.DataAdapter gehört.) Ich öffnete die .csproj-Datei direkt und konnte sie korrekt ausführen Setzen Sie den Haltepunkt.)

4
Steffen Winkler

Wenn es keine besseren Alternativen gibt, können Sie den Haltepunkt in den Code einfügen:

System.Diagnostics.Debugger.Break();

Vergiss nicht, es danach zu entfernen ...

4
bdrajer

Ich hatte heute das gleiche Problem. Ich konnte es auf die Tatsache zurückführen, dass ich beim Debuggen vergessen hatte, das Plattformziel auf x86 festzulegen. Leider können die anderen (x64/Any CPU) beim Debuggen problematisch sein. Zumindest VS 2008 mag sie nicht. Ich denke, das ist ein weiterer Grund, um weg zu bleiben.

Einige Spekulationen ... Ich denke, dass der Debugger (während er eine 64-Bit-App ausführt) in bestimmten Fällen Breakpoints aus einer Datei "stiehlt". Für mich war es, weil zuerst eine andere Assembly geladen wurde, die den gleichen Dateinamen hatte. Ich konnte das Problem auch im 64-Bit-Modus vermeiden, wenn ich die Assembly zuerst manuell mit meinen Haltepunkten geladen habe: Assembly.Load ("MyAssemblyWithBreakpoints");

Hoffe das hilft (mein erster Stackoverflow-Beitrag).

3
David Beavon

Ich hatte gerade dieses Problem in Visual Studio 2017 (Version 15.9.7), wo Unterbrechungspunkte übersprungen wurden und der Debugger einfach über Rückgabeanweisungen "übersprang".

Nach einer Weile bemerkte ich, dass ich dem Projekt kürzlich eine .runsettings-Datei hinzugefügt habe - und es stellte sich heraus, dass in meinem Fall das Konfigurieren des CodeCoverage-Datenkollektors dieses Problem verursacht. Sobald ich diesen Abschnitt entfernt habe:

<DataCollector friendlyName="Code Coverage" uri="datacollector://Microsoft/CodeCoverage/2.0" assemblyQualifiedName="Microsoft.VisualStudio.Coverage.DynamicCoverageDataCollector, Microsoft.VisualStudio.TraceCollector, Version=11.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"> ... </DataCollector>

in der .runsettings-Datei hat es wieder wie ein Zauber gewirkt.

2
DSpirit

Ich habe gerade die Datei gesichert und gelöscht und dann wieder zum Projekt hinzugefügt, das das Problem gelöst hat. Ich wünschte nur, ich hätte es getan, bevor ich die oben genannte Liste durchgegangen bin :)

1
Jan Lecko

Ich habe dieses Problem in Visual Studio 2015 gelöst.

Ich hatte einen Unterordner mit einem DLL, den ich als Version1 speichern wollte. Es scheint, selbst nachdem der Verweis auf diese DLL entfernt und dann ein Verweis zu einem anderen Projektstudio hinzugefügt wurde, der vorhandene Verweis gezogen und die falsche Quelldatei aufgerufen wurde. Ich habe das DLL im Unterordner entfernt, dann bekam Studio die richtige Quelle.

Ich habe auf [MSDN] einen hilfreichen Link gefunden, der zeigt, wie frühere zugehörige Quelldateien im Studio unter diesem Link gelöscht werden] [1].

Zusammenfassung:

  1. Klicken Sie im Projektmappen-Explorer mit der rechten Maustaste auf den Lösungsnamen (Beispiel: Lösung 'TestApplication'), und wählen Sie Eigenschaften aus. Das Dialogfeld "Lösungs-Eigenschaftenseiten" wird angezeigt
  2. Wählen Sie unter Allgemeine Eigenschaften Debug-Quelldateien aus
  3. Fügen Sie im Feld Diese Pfade nach Quellcodedateien durchsuchen (Visual Studio .NET 2003)/Verzeichnisse mit Quellcode (Visual Studio 2005) die Verzeichnisse nach Bedarf hinzu, entfernen Sie sie und/oder ordnen Sie sie neu
  4. Klicken Sie auf die Schaltfläche OK
1
Patrick

Obwohl das Umbenennen einer der Dateien funktioniert, habe ich festgestellt, dass die einfachste Lösung das automatische Laden von Symbolen für die "andere" Assembly vorübergehend deaktiviert.

  1. Starten Sie den Debugger und fahren Sie fort, bis Sie den fehlerhaften Haltepunkt erreicht haben.
  2. Finden Sie, wo der Debugger tatsächlich den Haltepunkt mithilfe des Call Stack Fensters festlegt:
    1. Klicken Sie mit der rechten Maustaste auf die Zeile mit dem gelben Pfeil und aktivieren Sie Show Module Names . (In der Zeile sollte auch das rote Haltepunktsymbol angezeigt werden.)
    2. Der Assemblyname ist jetzt in dieser Zeile sichtbar.
  3. Suchen Sie diese Baugruppe im Modulfenster ( Debug> Windows> Module ).
  4. Klicken Sie mit der rechten Maustaste auf die Assembly und deaktivieren Sie Always Loading Automatic .
  5. Stoppen Sie den Debugger. 
  6. Beginnen Sie erneut mit dem Debuggen.

Auf diese Weise verhindern Sie, dass der Visual Studio-Debugger den Haltepunkt der falschen Assembly zuordnet. Die Symbole werden dann zuerst von der anderen [vermutlich korrekten Assembly] geladen, sodass der Haltepunkt der richtigen Assembly zugeordnet wird.

Warum passiert das?

Dies scheint der Fall zu sein, wenn zwei verschiedene Symboldateien (PDB-Dateien) - für zwei verschiedene Assemblys - beide auf eine Quelldatei mit demselben Namen verweisen. Obwohl die Quelldateien völlig unterschiedlich sind, scheint der Visual Studio-Debugger verwirrt zu sein.

Stellen Sie sich beispielsweise vor, es gibt zwei verschiedene Dateien mit dem Namen IdeasController.cs. Der erste wird in Assembly Api.dll und der zweite in Assembly Web.dll kompiliert. 

Wenn der Debugger Symbole lädt, lädt er zuerst Api.pdb oder Web.pdb. Nehmen wir an, es lädt zuerst Api.pdb. Selbst wenn Sie in Web\IdeasController.cs einen Haltepunkt setzen, wird in IdeasController.cs eine Übereinstimmung für Api.pdb gefunden. Es ordnet dann den Code von Web\IdeasController.cs zu Api.dll zu. Dies wird natürlich nicht korrekt zugeordnet. Daher werden beim Debuggen alle möglichen seltsamen Probleme angezeigt.

1
Malarial

Ich hatte ein sehr ähnliches Problem. In meinem Fall war das Problem ein anderes Ziel-.NET-Framework in einem der Projekte, das dazu führte, dass VS2017 fälschlicherweise eine Quelldatei (mit demselben Namen) eines anderen Projekts lud und nicht die, mit der aktiviert wurde

ObjectHandle handle = Activator.CreateInstance

Es wurde behoben, dass das Zielframework des Projekts in allen Projekten gleich war.

0
Stefan Michev

Löschen Sie alle .pdb-Dateien des Projekts, an denen der Haltepunkt falsch angezeigt wird. Dies löst das Problem.

0
Ramaraj K

Es passierte mir (in VS 2008 ), zwei untergeordnete Haltepunkte mit der gleichen Speicheradresse zu haben und der gleichen zugehörigen Datei . Diese Haltepunkte wurden zu einem bestimmten Zeitpunkt erzeugt während des laufenden Prozesses.

Ich habe festgestellt, dass ich .dll-Dateien in meinen Projektordnern dupliziert hatte, und das Entfernen des duplizierten .dlllöste, wobei jedoch nur ein .dll pro Name in der Debugging-Ordnerstruktur beibehalten wurde. (Als Beispiel in meinem Fall hatte ich /bin/Example.dll und /bin/Plug-in/Example.dll in meiner Debug-Ordnerstruktur.).

0
Simone

Was für mich funktionierte (VS2017) war Deaktivieren Diese Option in Tools --> Options... --> Debugging --> General: " Quelldateien müssen genau mit der Originalversion übereinstimmen ", die standardmäßig aktiviert ist, aber ich hatte sie eingeschaltet.

Das war jedoch nicht genug, ich musste auch obj und bin Ordner für alle Projekte in der Lösung manuell entfernen. 

0
batintherain

Sie können auch versuchen, alle Projekte zu bereinigen und neu zu erstellen (nicht zu erstellen).

0
Diogo