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.

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!

Hallo Wilfried,

das kann kein generelles Problem unter 64-Bit sein. Hast du eventuell keinen Standarddrucker eingerichtet? Falls doch, dann setze mal einen anderen auf Standard, vielleicht geht es dann. So etwas ähnliches hatte ich auch schon in Excel.

Gruß,
Daniel

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.

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.

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