Laden...

Debuggen einer DLL mit externem Prozess

Erstellt von xdaniel vor 11 Jahren Letzter Beitrag vor 11 Jahren 2.260 Views
X
xdaniel Themenstarter:in
6 Beiträge seit 2012
vor 11 Jahren
Debuggen einer DLL mit externem Prozess

Hallo,

folgendes Problem stellt sich beim Debuggen von DLLs in unserer Firma:

Wir haben ein zentrales Verzeichnis im Netzwerk, in dem unsere Hauptanwendung inkl. aller DLLs stehen (Entwicklungsversion).

Jeder Entwickler hat seine eigenen Projekte auf einem eigenen Laufwerk. Wenn man nun eine Klassenbibliothek in Verbindung mit der Hauptanwendung debuggen möchte, dann kann man die Anwendung ja als externes Programm starten und sich an den Prozess anhängen usw.
Das Problem dabei ist, dass die DLL im Debug-Ordner meines Projektes exakt die gleiche sein muss, wie die im Anwendungsverzeichnis, ansonsten hält VS nicht bei meinen Breakpoints an. Wenn ich dauernd Änderungen mache, muss ich meine DLL immer erst ins Anwendungsverzeichnis kopieren - was

  1. lästig ist
  2. nicht immer funktioniert, weil sie gerade in Benutzung ist
  3. nicht immer gewollt ist, dass eine unstabile Testversion gleich im zentralen Ordner für alle nutzbar ist

Gibt es eine Einstellung o.ä., mit der man angeben kann, dass die DLL im zentralen Verzeichnis ignoriert wird und direkt aus meinem Projekt genutzt wird?

Danke im Voraus!
Daniel

G
538 Beiträge seit 2008
vor 11 Jahren

Für mich klingt das nach einem Fall in dem ein Repository wahre Wunder wirken könnte: zum Beispiel GIT oder Mercurial.

Damit könnte jeder eine Lokale Kopie der zentralen Anwendung haben und diese auf seinem PC starten. Dann hat man keine Probleme mit Locks, unstabilen Versionen auf dem Share oder ähnlichem.

Der Vorteil der Klugheit liegt darin, dass man sich dumm stellen kann - umgekehrt ist das schon schwieriger (K. Tucholsky)
Das Problem mit Internet-Zitaten ist, dass sie oftmals zu unrecht als authentisch angenommen werden. (K. Adenauer)

X
xdaniel Themenstarter:in
6 Beiträge seit 2012
vor 11 Jahren

Hhmm...

Das ist nicht so einfach. Unsere Anwendung besteht nur zum Teil aus .Net-Programmen. Der überwiegende Teil sind zurzeit unmanaged COBOL-Dlls (ca. 2.000 Stück). Das macht wohl keinen Sinn, die jedes Mal alles in jedes Projekt zu kopieren.

Mein beschriebenes Problem kenne ich aus anderen Entwicklungsumgebungen nicht, dort spielt es keine Rolle, welchen Stand die DLL im Anwendungsordner hat. Es wird immer die aktuelle aus dem Projektverzeichnis verwendet.
Daher hätte ich gehofft, dass ich diese Möglichkeit in Visual Studio bislang nur einfach noch nicht gefunden habe.

5.742 Beiträge seit 2007
vor 11 Jahren

Hallo xdaniel,

auch wenn man dafür im Normalfall Quellcodeverwaltungen und Librarymanager einsetzt, kannst du dafür das Postbuild Event von VS in Kombination mit robocopy missbrauchen.

X
xdaniel Themenstarter:in
6 Beiträge seit 2012
vor 11 Jahren

Dann hätte ich aber immer noch das Problem, dass die DLL gesperrt sein könnte (kann man natürlich auch lösen, indem sie vorher umbenennt) und vor allen Dingen die Tatsache, dass ich nicht jeden Entwicklungsstand, den ich testen möchte, auch zentral freigeben möchte.

T
2.219 Beiträge seit 2008
vor 11 Jahren

Ich kann euch auch nur dringend ein Repository mit Git, Mercurial oder SVN empfehlen.
Warum ihr 2.000 Cobol DLLs habt und davon abhängig seit ist mir nicht klar.

Verwendet ihr alle DLLs in einem Programm oder haben sich diese bei euch nur angesammelt im laufe der Zeit?

Hier müsstest ihr die DLLs in ein eigenes Repository packen.
Benötigte DLLs müssen dann nur in das Repository abgelegt werden in dem diese benötigt werden, was auch mehr Sinn macht als alle zentral zu sammeln.

Den eure aktuelle Entwicklungsmethode ist ehrlich gesagt blödsinn.
Wenn es in einem kommerziellen Umfeld ist würde ich mir erst recht Gedanken machen über solche Arbeitsabläufe.

Wir arbeiten bei uns auch über ein zentrale SVN Repository und haben jeweils unsere Versionen auf der Platte und gleiche diese nur mit den Repositories ab.
Klar kommen dabei auch doppelte DLLs und co vor aber so funktioniert es nun mal sinnvollsten.

T-Virus

Developer, Developer, Developer, Developer....

99 little bugs in the code, 99 little bugs. Take one down, patch it around, 117 little bugs in the code.

5.742 Beiträge seit 2007
vor 11 Jahren

dass ich nicht jeden Entwicklungsstand, den ich testen möchte, auch zentral freigeben möchte.

Du sollst ja auch nicht deinen Entwicklungsstand kopieren, sondern den aktuellen Stand des Netzlaufwerkes auf deinen Rechner bzw. in ein separates Verzeichnis.

Wenn ihr - wie man das aus deiner Beschriebung ableiten könnte - tatsächlich nur eine Instanz der Anwendung "für alle" haben solltet, sind derartige Probleme natürlich vorprogrammiert.

X
xdaniel Themenstarter:in
6 Beiträge seit 2012
vor 11 Jahren

Ok, dann werde ich wohl nicht drumherum kommen. Für .NET-Projekte nutzen wir bereits den TFS, nur für die COBOL-Dlls (ja, es werden alle 2.000 gebraucht) gibt es bislang keine vernünftige Lösung.

Trotzdem danke für die Hinweise!

T
2.219 Beiträge seit 2008
vor 11 Jahren

Wenn ihr - wie man das aus deiner Beschriebung ableiten könnte - tatsächlich nur eine Instanz der Anwendung "für alle" haben solltet, sind derartige Probleme natürlich vorprogrammiert.

Und deshalb spricht sogar noch mehr für ein zentrales Repository.
Dort werden nur stabile Änderungen im Normalfall comittet.

Auch habt ihr dann Vorteile wie Branches mit denen ihr euch Snapshots der letzten Versionen erstellen könnt.
Dadurch können Erweiterungen im Hauptzweig und Korrekturen im Branch zur entsprechenden Version gepflegt werden.

Somit trennt ihr euren Entwicklungsstand nochmals von den stabilen Versionen ab.
Noch besser kann man es nicht haben.

Und meine Meinung zu der Shares Lösung ist im oberen Beitrag bereits verfasst.

Nachtrag:
Wenn ihr schon den TFS habt was ist dann das Problem mit den DLLs?
Diese sollte der TFS auch speichern und verteilen können.

Aber warum braucht ihr ernsthaft 2.000 DLLs?
Ich gehe davon aus, dass ihr in eurem Projekt ein Program habt das diese nutzt.
Und das scheint mir arg sinnfrei.

T-Virus

Developer, Developer, Developer, Developer....

99 little bugs in the code, 99 little bugs. Take one down, patch it around, 117 little bugs in the code.

G
538 Beiträge seit 2008
vor 11 Jahren

Das ist nicht so einfach. Unsere Anwendung besteht nur zum Teil aus .Net-Programmen. Der überwiegende Teil sind zurzeit unmanaged COBOL-Dlls (ca. 2.000 Stück). Das macht wohl keinen Sinn, die jedes Mal alles in jedes Projekt zu kopieren.

Du musst sie nicht jedes mal kopieren ein Repository zeichnet sich ja grade dadurch aus, dass es nur geänderte Dateien überträgt. Und den Rest schafft man wie winsharp93 schon gesagt hat mit ein paar Post-Build-Events und Robocopy ...

Mein beschriebenes Problem kenne ich aus anderen Entwicklungsumgebungen nicht, dort spielt es keine Rolle, welchen Stand die DLL im Anwendungsordner hat. Es wird immer die aktuelle aus dem Projektverzeichnis verwendet.
Daher hätte ich gehofft, dass ich diese Möglichkeit in Visual Studio bislang nur einfach noch nicht gefunden habe.

Wie willst du ordentlich debuggen, wenn es nicht die gleichen sind?

Der Vorteil der Klugheit liegt darin, dass man sich dumm stellen kann - umgekehrt ist das schon schwieriger (K. Tucholsky)
Das Problem mit Internet-Zitaten ist, dass sie oftmals zu unrecht als authentisch angenommen werden. (K. Adenauer)

X
xdaniel Themenstarter:in
6 Beiträge seit 2012
vor 11 Jahren

Wie willst du ordentlich debuggen, wenn es nicht die gleichen sind?

Naja, indem die freigegebene ignoriert und nur die aus meinem Projekt verwendet wird. Mit COBOL ist das kein Problem.

Aber ich sehe ein, dass es in VS solche Möglichkeiten nicht gibt und ich mir mal genauere Gedanken über eine ordentliche Verwaltung ALLER Dlls machen muss.

T
2.219 Beiträge seit 2008
vor 11 Jahren

Das hätte schon zu beginn des Projekts passieren sollen.
Und wie geschrieben empfehle ich dringend ein Repository.

T-Virus

Developer, Developer, Developer, Developer....

99 little bugs in the code, 99 little bugs. Take one down, patch it around, 117 little bugs in the code.