Visual Studio breakpoints break in die falsche Quell-Datei (oder mehrere Dateien gleichzeitig) wenn mehrere Dateien den selben Namen haben

In einem team-Projekt an dem ich arbeite, setzen einen breakpoint in einer Datei (sagen IdeasController.cs) führen zu erratischen debugger Verhalten, wenn Sie eine andere Datei mit dem gleichen Namen in der Lösung. Ich habe reproduzierte das problem auf mehreren Entwickler-workstations.

Beispiel

Ich einen Haltepunkt in IdeasController.cs in unserem Web-API:

Visual Studio breakpoints break in die falsche Quell-Datei (oder mehrere Dateien gleichzeitig) wenn mehrere Dateien den selben Namen haben

Einer anderen Datei aufgerufen IdeasController.cs gibt es in unserem separaten MVC 4 web-Projekt. In der Abbildung unten, der debugger zeigt die Api->IdeasController source-code, aber die Zeile markieren, mit der code-Struktur von Web->IdeasController. Der Haltepunkt wird dupliziert, mit einem von Ihnen in der Mitte von einem Kommentar-block.

Visual Studio breakpoints break in die falsche Quell-Datei (oder mehrere Dateien gleichzeitig) wenn mehrere Dateien den selben Namen haben

Breakpoint-Fenster zeigt den Haltepunkt in beiden Dateien gleichzeitig:

Visual Studio breakpoints break in die falsche Quell-Datei (oder mehrere Dateien gleichzeitig) wenn mehrere Dateien den selben Namen haben

Auf einigen workstations der debugger durch die richtigen Zeilen (unabhängig von der line, highlight); auf andere, die es fröhlich Schritte durch irrelevante Zeilen (inklusive Kommentare und Leerzeichen). Ich vermute, dies hängt davon ab, welche Quellcode-Datei, die es wählt, um anzuzeigen.

, Was ich versucht habe

Habe ich surften im Internet. Diese Art von problem scheint aufzutreten, wenn es eine Diskrepanz zwischen der debug-Datei (*.pdb), die Quell-Datei und das kompilierte code. Es gibt viele mögliche Ursachen: doppelte Datei-Namen (das kann verwirren den debugger " [5]), veraltete Projekt-build-Dateien, ungültige Lösung cache, oder fehlerhafte build-Konfiguration.

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

  • Überprüft meine build-Konfiguration.
    1. Sorgte dafür, dass das Projekt nicht gebaut im release-Modus.
    2. Dass wir nicht über code-Optimierung aktiviert.
    3. Sorgte dafür, dass das Projekt die debug-Modul wurde ordnungsgemäß geladen. (Begonnen wurde das Projekt Debuggen und überprüft Debug > Windows > Modules. Beide Assemblys aufgeführt sind, nicht optimiert und haben ein status-symbol "Symbole laden".)
  • Zurücksetzen der debugging-Metadaten & Visual Studio cache.
    1. Geschlossen Visual Studio gelöscht und die Lösung der cache-Datei (*.suo).[1]
    2. Gelöscht jedes Projekt die build-Ausgabe (die bin und obj Ordner). (Zum nachlesen: öffnen Sie den Projektmappen-Ordner im Windows-Explorer, und geben Sie diesen in das Suchfeld ein: "type:folder AND (name:=bin OR name:=obj)".
    3. Gelöscht assembly cache-Ordner (C:\Documents and Settings\<user>\Local Settings\Application Data\dl3).[2][3]

Keiner von diesen hatte, keine Wirkung. Ich kann benennen Sie eine der Dateien (ohne umbenennen der Klasse), um vorübergehend das problem zu umgehen, aber das ist weit vom ideal entfernt.

, Wo ich jetzt bin

Seite 14 von meiner letzten Google-Suche. Anregungen wäre sehr geschätzt werden. 🙂

  • Ja, wirklich ärgerlich. Dieser bug ist mindestens seit Visual Studio 2008. Die einzige Lösung die ich kenne besteht darin, ein umbenennen der Quelldatei als Sie herausgefunden haben, auf Ihrem eigenen.
  • Interessanterweise, dieser Fehler ist in der Dokumentation erwähnt: msdn.microsoft.com/en-us/library/h6aesyw2%28v=vs.100%29.aspx . Aber die Problemumgehung, die Sie vorschlagen, (geben Sie den vollständigen Pfad der Quelldatei manuell) scheint nicht zu funktionieren, zumindest bei mir in VS 2013 U2.
  • Noch geschieht in Visual Studio 2015
InformationsquelleAutor Pathoschild | 2012-09-13
  1. 6

    Ich bin so froh, dass ich fand diesen Beitrag, dachte ich war der einzige, und das war verrückt! Ich bin mit dem gleichen problem in VS2012 mit VB.Net und die haben alles versucht die OP erwähnt.

    Eindeutige Benennung der Dateien scheint das einzige zu sein, 100% fix, dass ich gefunden habe. Deaktivieren Sie alle Haltepunkte, bis die Anwendung geladen ist und dann re-aktivieren Sie die Haltepunkte, die Sie benötigen, arbeitet die meiste Zeit. Haltepunkte in Lambda-Funktionen können immer noch geben Ihnen Probleme.

    InformationsquelleAutor Miiir
  2. 5

    Wenn keine besseren alternativen vorhanden sind, könnte man den Haltepunkt im code:

    System.Diagnostics.Debugger.Break();

    Nur vergessen Sie nicht, um es zu entfernen danach...

    InformationsquelleAutor bdrajer
  3. 4

    Ich hatte gerade das exakt gleiche problem. Was löste es bei mir war, löschen .suo-Dateien gehören zu der Lösung, die das betroffene Projekt/Quell-Datei.

    Ich auch gelöscht, meine lokalen symbolcache aber ich glaube nicht, dass hatte nichts damit zu tun.

    (Meine Projektmappe mehrere Projekte enthält, wird eine Datei (DataAdapter.cs) in einem Projekt betroffenen (VisualStudio meine Haltepunkte in der pdb-Zugehörigkeit zum System.Daten.DataAdapter). Ich öffnete die .csproj-Datei direkt und war in der Lage, richtig der der Haltepunkt gesetzt wurde.)

    • Ich weiß nicht warum, aber das löschen der .suo mein problem lösen. Ich habe gerade dupliziert mein Projekt in ein anderes Projekt mit anderen Namen. Wenn ich debug das neue Projekt, die Seite halten, ruft das alte Projekt. Gleiche für den Haltepunkt. Jetzt funktioniert ' s einwandfrei. Vielen Dank für die Rettung meiner Zeit, nach 3 Stunden verschwenden
    InformationsquelleAutor Steffen Winkler
  4. 3

    Ich hatte das gleiche problem heute. Ich war in der Lage zu verfolgen es zurück zu der Tatsache, dass ich vergessen hatte, um die Plattform Ziel auf x 86 während des Debuggens. Leider sind die anderen (x64 /Alle-CPU) kann problematisch sein beim Debuggen. Mindestens VS 2008 nicht mag. Ich denke, das ist ein weiterer Grund zu bleiben Weg.

    Einige Spekulationen... ich glaube der debugger (während der Ausführung einer 64-bit-app) irgendwie "Stiehlt" Haltepunkte entfernt aus einer Datei in bestimmten Fällen. Für mich war es wegen einer anderen assembly geladen wurde, sind die ersten, die den gleichen Datei-Namen. Ich war in der Lage, um das Problem zu vermeiden, auch im 64 bit-Modus, wenn ich vorher manuell geladen, die Versammlung mit meinem Haltepunkte: Montage.Laden("MyAssemblyWithBreakpoints");

    Hoffe, dass diese (meine erste stackoverflow-Beitrag) hilft.

    InformationsquelleAutor David Beavon
  5. 2

    Ich hatte gerade dieses Problem auf Visual Studio-2017 (Version 15.9.7), wurden in der Pause Punkte übersprungen wurden, und der debugger nur "sprang" über die return-Anweisungen etc.

    Nach einer Weile bemerkte ich, dass ich habe vor kurzem einen .runsettings-Datei zum Projekt - und es stellte sich heraus, dass in meinem Fall die Konfiguration der CodeCoverage-Daten-Sammler ist dieses problem verursacht.
    Sobald ich entfernt, dieser Abschnitt:

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

    aus der .runsettings-Datei, es funktioniert wie ein Charme wieder.

    InformationsquelleAutor DSpirit
  6. 1

    Ich gerade gesichert und die Datei gelöscht und dann wieder Hinzugefügt, um das Projekt, dass das problem gelöst ist. Ich nur Wunsch ich es Tat, bevor er durch die beforementioned Liste 🙂

    • Dies ist die einzige Lösung, die für mich gearbeitet, versuchen Sie diese zuerst
    InformationsquelleAutor Jan Lecko
  7. 1

    Ich traf dieses Problem in Visual Studio 2015.

    Hatte ich einen sub-Ordner mit einer DLL, die ich retten wollte, als Version1. Es scheint, dass selbst nach dem entfernen der Referenz auf die DLL, und klicken Sie dann hinzufügen einen Verweis auf ein anderes Projekt studio zog in die bestehende Referenz-und der ging an die falsche Quelle-Datei. Entfernt habe ich diese DLL in den Unterordner dann Studio hat die richtige Quelle.

    Fand ich einen hilfreichen link auf [MSDN, zeigt, wie klar vor der zugeordneten Quell-Dateien in studio unter diesem link][1].

    Zusammenfassung:

    1. Im Projektmappen-Explorer mit der rechten Maustaste auf der name der Lösung (ex: Lösung "TestApplication") und wählen Sie Eigenschaften, um die Eigenschaftenseiten-Dialogfeld
    2. Unter Allgemeine Eigenschaften, wählen Sie Debug Quellcode-Dateien
    3. In der Suche diese Pfade für die Quell-code-Dateien (Visual Studio .NET 2003) /Verzeichnisse mit Quellcode (Visual Studio 2005) - box, hinzufügen, entfernen und/oder die Reihenfolge der Verzeichnisse wie gewünscht
    4. Klicken Sie auf die Schaltfläche OK
    InformationsquelleAutor Patrick
  8. 1

    Obwohl das umbenennen einer Datei funktioniert, ich fand, dass die einfachste Lösung ist, um vorübergehend deaktivieren Sie die automatische laden von Symbolen für die "anderen" - Montage.

    1. Den debugger starten und weiter, bis Sie auf die falschen Haltepunkt.
    2. Finden, wo der debugger eigentlich legen Sie den Haltepunkt mit dem Call-Stack Fenster:
      1. Mit der rechten Maustaste auf die Zeile mit dem gelben Pfeil, und aktivieren Sie Zeigen Modul-Namen. (Die Zeile müsste auch die rot-Haltepunkt-symbol auf es.)
      2. Name der assembly ist jetzt sichtbar auf der Zeile.
    3. Finden, dass die Montage in das Fenster Module (Fehler - > Windows - > Module).
    4. Mit der rechten Maustaste auf die Baugruppe, und deaktivieren Sie Immer Automatisch Geladen.
    5. Stoppen Sie den debugger.
    6. Starten Sie das Debuggen wieder.

    Durch, dies zu tun, Sie sind die Verhinderung der Visual Studio-debugger von der Zuordnung der Haltepunkt an der falschen Montage. Es wird dann das laden der Symbole aus der anderen [vermutlich] die korrekte Montage an Erster Stelle, deshalb Zuordnung der Haltepunkt, um die korrekte Montage.

    Warum geschieht dies?

    Dies scheint aufzutreten, wenn zwei verschiedene symbol-Dateien (PDB-Dateien) — für zwei verschiedene Baugruppen — beide verweisen auf eine source-Datei mit dem gleichen Namen. Obwohl die source-Dateien sind komplett anders, die Visual Studio debuggger scheint verwirrt.

    Angenommen, es gibt zwei verschiedene Dateien mit dem Namen IdeasController.cs. Die erste kompiliert in der Montage -Api.dll, und die zweite in einer assembly kompiliert Web.dll.

    Wenn der debugger lädt Symbole, es wird legen Sie entweder Api.pdb oder Web.pdb ersten. Sagen wir, es lädt Api.pdb ersten. Dann, auch wenn Sie einen Haltepunkt in Web\IdeasController.cs es wird eine übereinstimmung gefunden, für IdeasController.cs im Api.pdb. Es ordnet dann code aus Web\IdeasController.cs zu Api.dll. Diese werden nicht korrekt zugeordnet, natürlich, und so werden Sie sehen, alle Arten von seltsamen Probleme beim Debuggen.

    InformationsquelleAutor Malarial
  9. 0

    Können Sie auch versuchen, zu Reinigen und neu erstellen (nicht Bauen) alle Projekte.

    InformationsquelleAutor Diogo
  10. 0

    Was für mich gearbeitet (VS2017) war deaktivieren diese option in Tools --> Options... --> Debugging --> General: "Erfordern Quellen, die Dateien exakt die ursprüngliche version", die standardmäßig aktiviert ist, aber ich hatte es eingeschaltet.

    War das nicht genug, obwohl, das musste ich auch manuell entfernen obj und bin Ordner für alle Projekte in Lösung.

    InformationsquelleAutor batintherain
  11. 0

    Löschen Sie alle .pdb-Dateien des Projekts, wo der Haltepunkt ist, zu schlagen, zu Unrecht. Diese werden das Problem zu lösen.

    InformationsquelleAutor Ramaraj K
  12. 0

    Ist es mir passiert (in VS 2008) haben zwei Kind Haltepunkt mit der gleichen Speicher-Adresse und die gleiche zugehörige Datei.
    Diese Haltepunkte erzeugt wurden, zu einem bestimmten Zeitpunkt während der Ausführung des Prozesses.

    Bemerkte ich, dass ich dupliziert hatte .dll Dateien in meinem Projekt Ordner, und behoben, entfernen Sie den doppelten .dll, während nur ein .dll pro name in der debugging-Ordner-Struktur. (Als Beispiel in meinem Fall hatte ich /bin/Example.dll und /bin/Plug-in/Example.dll beiden präsentieren unter meine debug-Ordner-Struktur).

    InformationsquelleAutor Simone
  13. 0

    Ich hatte ein sehr ähnliches problem. In meinem Fall war das problem ein anderes Ziel .net framework Projekte verursacht VS2017 zu Unrecht Last einer Quellcode-Datei (mit gleichem Namen) von einem anderen Projekt, nicht die, die aktiviert wird mit

    ObjectHandle handle = Activator.CreateInstance

    Ändern zielframework des Projekts werden die gleichen in allen Projekten behoben.

    InformationsquelleAutor Stefan Michev
Schreibe einen Kommentar