2010-10-08 3 views
5

Wir haben oft eine Reihe von gemeinsamen Kern-Bibliotheken, die wir für einige unserer Entwicklung sie als DLL-Referenzen denken und somit nur die DLLs verweisen und nicht die Projektdatei.Gibt es eine einfache Möglichkeit, zwischen einem Projekt und seiner DLL zu wechseln

Andere Zeiten benötigen wir alle Projekte für eine intime Debugging-Sitzung. Ich kann nicht nur Uber.sln und Core.sln haben, da die Referenzen in den Projektdateien sind. Ich habe diese Frage seit mehreren Jahren in verschiedenen Projekten, aber habe keine andere Lösung, als eine Uber.sln mit den 50 Projekten zu haben.

Alle Ideen/Hinweise/Richtungen willkommen!

Antwort

2

Solange die DLLs mit Debug erstellt werden und Sie die PDBs haben, müssen Sie es nicht als "Projektreferenz" enthalten.

Sie werden nach dem Quellcode gefragt, oder Sie können einfach den Quellcode in der Lösung öffnen und einen Haltepunkt setzen.

How to show source code in debug when using .lib and dll

+0

+1, yup. Es hat selten Probleme, die .pdb-Datei zu finden, solange sie sich noch im ursprünglichen Build-Ordner befindet. –

2

dlls in ihrem eigenen Projekt oder Projekte geteilt entwickeln. Kompilieren Sie sie und fügen Sie sie einem lib-Ordner in Ihren Projekten hinzu, die auf sie verweisen.
einen dev Baum wie folgt erstellen:

/lib 
shareddlls go here 
/src 
solution.sln 
/projectfolder 
    project.proj 
/tools 
testing frameworks 

Wenn Sie in VS debuggen und gehen in Ihre eigene DLLs sollten Sie noch in der Lage sein, den Code so dass keine Notwendigkeit zu sehen, die gemeinsam genutzten DLLs zu einem uber Projekt hinzuzufügen. Wenn Sie den Code nicht sehen können, dann behandeln Sie ihn als Black Box. Debuggen, was hineingeht und was herauskommt. Wenn es nicht das ist, was Sie erwarten, liegt das Problem in den gemeinsamen DLLs. Gehen Sie und debuggen Sie sie in ihren eigenen Projekten.

Verwenden Sie ein Testframework, um Ihre freigegebenen DLLs in ihrem eigenen Projekt zu testen. -----

+0

Es gibt Zeiten, wenn Sie Features entwickeln möchten, die die geteilten DLLs und die Anwendungs-DLLs kreuzen. In diesen Zeiten zahlt sich eine große Lösung aus. Es scheint nur eine Arbeitsweise zu sein, die von MS nicht unterstützt wird. – Squirrel

+0

@Squirrel Für mich ist das ein schlechtes Design. Jede Klasse sollte für eine Sache verantwortlich sein und ähnliche Projekte (dlls) sollten ähnliche Funktionen gruppieren. Bemühen Sie sich, Abhängigkeiten zu entfernen. – skyfoot

+0

Lassen Sie mich neu formulieren, dass Sie oft eine Debugging-Sitzung benötigen, bei der Sie eine Anfrage von der obersten Ebene Ihres Servers in die 'Komponenten'-DLLs verfolgen müssen. Sie erkennen, dass es ein Problem in der Komponente gibt, die behoben werden muss, aber wenn die Komponente eine DLL ist, müssen Sie die Komponentenlösung starten, die Komponente neu erstellen und dann diese eingebauten DLLs verwenden und die DLLs aktualisieren, die die Anwendungslösung/das Projekt ist zeigt auf. Alles in allem ist es ein bisschen eine Frage, also haben wir eine große Lösung. Keine der beiden Optionen ist ideal - kommt Ihnen dieses Szenario bekannt vor oder ist es nur ich? – Squirrel

1

Ich denke, die nächste Antwort, die ich gefunden habe, ist die Einbeziehung aller Projekte in der Lösung und auch ein DLL-Projekt, das beim kompilieren würde die Prod/Dosen Dlls an die Ausgabe dir senden.

Dann könnte ich mit verschiedenen Konfigurationen zwischen der Debug-Konfiguration mit den Projekten, die gebaut werden, in die Release-Konfiguration mit nur dem DLL-Projekt, das gebaut wird.

Geben Sie es und melden Sie zurück ....

+0

Hallo Eichhörnchen, wie hat es geklappt? Ich habe das selbe Problem wie du. Vielen Dank. – toddmo