2009-07-15 15 views
91

Meine Frage betrifft die mit Visual Studio 2008 debuggen, obwohl ich es nehme in VS2005, dass gleich sein sollteWie eine referenzierte dll (mit PDB)

Ich habe zwei Lösungen in meinem Arbeitsplatz, sagen A und B.

Lösung A ist ein älteres Projekt, das ich vor einiger Zeit abgeschlossen habe. In Lösung B muss ich einige Klassen aus Lösung A verwenden. Dazu füge ich einen Verweis auf die DLL eines der Projekte in Lösung A.

Das Problem ist, wenn ich versuche, zu debuggen. Ich möchte auch in A's Code einsteigen können. Visual Studio kann den Code für diese Klassen nicht laden ("Es ist kein Quellcode für den aktuellen Speicherort verfügbar.") Und ich kann nur die Disassemblierung anzeigen, was nicht sinnvoll ist.

Der einzige Weg, ich Debug-Klassen aus der Lösung A weiß, ist durch Lösung B ausgeführt wird, alle Prozesse lösen (im Debug-Menüpunkt) und befestigen Sie den Prozess aus der Lösung A.

Dies ist jedoch sehr umständlich und Ich kann nur A oder B auf einmal debuggen.

Gibt es eine Möglichkeit, den Code der referenzierten DLLs (für die ich den Quellcode habe) zu betreten?


Lösung: Mein Fehler war, dass ich dachte, dass ein Projekt nur einen Teil einer einzigen Lösung sein kann. Tatsächlich kann ein Projekt Teil einer beliebigen Anzahl von Lösungen sein.
Wenn Sie auf das alte Projekt verweisen müssen, fügen Sie das Projekt einfach zur Lösung hinzu. Dazu klicken Sie mit der rechten Maustaste auf die neue Lösung im Projektmappen-Explorer> Hinzufügen> Vorhandenes Projekt.
Dann können Sie die Projektreferenz hinzufügen. Wie andere geschrieben haben, sollten Sie wahrscheinlich vollständig vermeiden, DLL-Verweise auf Ihren eigenen Code (oder anderen Code, den Sie möglicherweise ändern und debuggen müssen) zu verwenden.

Eine sehr gute Referenz, wie Lösungen entworfen werden sollten, finden Sie in MSDN.

+0

Diese MSDN-Verknüpfung ist ein Muss für .NET-Entwickler (unabhängig von der von ihnen verwendeten Quellcodeverwaltung). Ich bin überrascht, dass ich es vorher nicht gesehen hatte. Vielen Dank! – Pat

Antwort

82

Wenn Sie ein Projekt Referenz haben, sollte es sofort funktionieren.

Wenn es sich um eine Datei (DLL) -Referenz handelt, müssen die Debugging-Symbole (die "pdb" -Datei) im selben Ordner wie die DLL sein. Überprüfen Sie, ob Ihre Projekte Debug-Symbole generieren (Projekteigenschaften => Build => Erweitert => Output/Debug Info = Full); und wenn Sie die DLL kopiert haben, legen Sie die PDB damit.

Sie können Symbole auch direkt in der IDE laden, wenn Sie keine Dateien kopieren möchten, aber es ist mehr Arbeit.

Die einfachste Möglichkeit ist die Verwendung von Projektreferenzen!

+3

Leider ist es meiner Meinung nach nicht möglich, einen Projektverweis zu einer anderen Lösung hinzuzufügen (korrigiere mich, wenn ich falsch liege!). – Elad

+0

Ja, Sie können. Ich benutze alle tiem, wenn nur ein Teil einer Bibliothek in einer neuen Lösung verwendet wird. – Wilhelm

+0

Könnten Sie bitte erklären, wie? Wenn ich auf "Verweis hinzufügen" klicke, werden auf der Registerkarte "Projekte" nur Projekte aus derselben Lösung angezeigt. – Elad

0

Es muss funktionieren. Ich habe benutzt, um eine .exe-Datei und eine DLL gleichzeitig zu debuggen! Was ich vorschlage, ist 1) Schließen Sie den Pfad der DLL in Ihrem B-Projekt, 2) Dann kompilieren Sie debuggen Ihr A-Projekt 3) Steuern, dass der Pfad auf der A dll und de pdb-Datei .... 4) Danach fängst du an, das B-Projekt zu debuggen und wenn alles in Ordnung ist, kannst du in beiden Projekten debuggen!

7

Ein weiterer zu beachtender Punkt ist, dass die referenzierten DLLs nicht im GAC installiert sind. Nach dem Testen habe ich meine DLLs in den GAC installiert, um Systemtests durchzuführen. Später, als ich meinen Code erneut debuggen musste, konnte ich nicht in die referenzierten Assemblys treten, bis ich sie aus dem GAC löschte.

+2

DANKE! Das war mein Problem. Ich kann nicht glauben, dass ich das nicht herausgefunden habe: -/Ich dachte, das Setzen des Projektverweises würde irgendwie überschreiben, was im GAC installiert war. – SnookerC

+0

Absolut! Das ist ein SEHR guter Punkt. Selbst wenn Sie die gleiche Version von .NET Framework haben, wenn Sie Code in der GAC haben, wenn Sie versuchen, zu debuggen, wird es den Haltepunkt nicht treffen, wenn die .PDB-Datei in der GAC ist anders als die in Ihrem Projektordner. Eine Lösung hierfür ist, die DLL zu un-GAC zu erstellen, dann die Assembly neu zu erstellen und dann zu reaktivieren. –

0

Ich möchte ein externes Klassenbibliotheksprojekt in einige meiner Lösungen nicht aufnehmen, also gehe ich in Assemblys, die ich auf andere Weise konsumiere.

Meine Lösungen haben ein "Common Assemblies" -Verzeichnis, das meine eigenen DLLs aus anderen Projekten enthält. Die DLLs, die ich referenziere, haben auch ihre zugehörigen PDB-Dateien zum Debuggen.

Um Debug-Punkte zu debuggen und setzen, setze ich einen Haltepunkt in der Quelle der verbrauchenden Anwendung, wo ich eine Methode oder Konstruktor von der Assembly aufrufen und dann INTO (F11) die Methode/Konstruktor aufrufen.

Der Debugger lädt die Quelldatei der Assembly in VS und neue Haltepunkte innerhalb der Assembly können an diesem Punkt gesetzt werden.

Es ist nicht einfach, funktioniert aber, wenn Sie keine neue Projektreferenz einfügen und stattdessen einfach auf eine freigegebene Assembly verweisen möchten.

21

Ich hatte das gleiche Problem. Er ist das, was ich gefunden:

1) sicherstellen, dass alle Projekte das gleiche Framework verwenden (das ist entscheidend)

2) in Extras/Optionen> Debuggen> Allgemein stellen Sie sicher, „Enable Just My-Code (Managed Only) ist NICHT angekreuzt

3) unter Extras/Optionen> Debugging> Symbole alle zwischengespeicherten Symbole löschen, alle Ordnerspeicherorte im Listenfeld "Symbole Datei (.pdb)" außer den Standard "Microsoft Symbol Servern" entfernen aber löschen Sie es immer noch. Löschen Sie auch alle statischen Pfade im Textfeld "Cache-Symbole in diesem Verzeichnis". Klicken Sie auf die Schaltfläche "Empty Symbols Cache". Stellen Sie sicher, dass das Optionsfeld "Only specified modules" aktiviert ist.

4) Stellen Sie im Menü Build/Configuration Manager für alle Projekte sicher, dass sich die Konfiguration im Debug-Modus befindet.

+2

Mein Problem war, dass meine beiden Projekte verschiedene .Net Frameworks verwendet haben: 4.0 und 4.5. Tx! – user627283

+1

Das hat für mich funktioniert. –

2

Wenn Sie einen Haltepunkt im Quellcode einer referenzierten DLL setzen möchten, stellen Sie zunächst sicher, dass Sie eine PDB-Datei dafür haben. Dann können Sie einfach die zugehörige Quellcodedatei öffnen und dort einen Haltepunkt setzen. Die Quelldatei muss nicht Teil Ihrer Lösung sein. Wie in How can I set a breakpoint in referenced code in Visual Studio?

erläutert. Sie können Ihre Haltepunkte über das Haltepunktfenster überprüfen, das über Debug -> Windows -> Breakpoints verfügbar ist.

Dieser Ansatz hat den Vorteil, dass Sie ein vorhandenes Projekt nicht nur zu Debugzwecken zu Ihrer Lösung hinzufügen müssen, da es mir viel Zeit für die Erstellung erspart hat. Offensichtlich ist es viel schneller, eine Lösung mit nur einem Projekt zu erstellen, als eine Lösung mit vielen davon zu erstellen.

+0

Dies funktioniert nur, wenn die externe Datei, in der Sie den Haltepunkt platziert haben, mit dem genauen Pfad in der PDB übereinstimmt. (Z. B. funktioniert nur, wenn Sie die DLL auf Ihrem Computer erstellt haben.) –

1

Schritt 1: Zum Tools -> Optionen -> Debuggen

Schritt 2: Uncheck My-Code

Aktivieren Gerade

Schritt 3: Uncheck erforderlich Quelldatei genau mit Original übereinstimmen Version

Schritt 4: Deaktivieren Sie Schritt über Eigenschaften und Operatoren

Verwandte Themen