[gelöst] Debugging über mehrere Projektmappen: Quellcode wird nicht immer gefunden

Sehr geehrte Damen und Herren,

Ich hätte ein paar Grundlegende Fragen zum Thema Debugging über Projektmappen hinweg.

Wir haben uns hier überlegt das wir in der Firma das Konstrukt der Projektmappe "abschaffen" wollen.
Der Hauptgrund liegt ganz eifnach an der Restriktion des Testzykluses (kein Arbeiten an Code der von der Abteilung getestet wird) und dadurch kommt es einfach zu doppelten Wartungsarbeiten bei Projektmappen.

Aufgrund dessen kam der Wunsch auf jede DLL und Programm in eine eigene Projektmappe zu legen.

Die Idee sah auf den ersten Blick sehr gut aus da das ofizielle Hauptargument für Projektmappender ist, das Visual Studio nur 1 mal gestartet sein muss. Jedoch bei näherer Überlegung kam mir das Problem des Debugging in den Sinn.

Zum Problem selbst:
Also unsere Kompilierungen und Quellcodestücke liegen auf 2 verschiedenen Servern (Verweise werden einfach mit einem fixen Pfad gesetzt also kein .Net Framework[Verweis hinzufügen -> durchsuchen]).
Wenn ich in Projektmappe 1 mein Programm debugge aber bei der Fehlersuche in eine DLL reindebuggen muss die auf der Programmserver liegt(ohne irgendwelche Debugginginformationen bei der DLL)aber der Quellcode zu der DLL in Projektmappe2 liegt habe ich doch hier ein Problem.

Teilweise findet VS den Quellcode und debugged "ganz normal" und manchmalspringt er einfach darüber weil er den SRC nicht findet.

Deswegen meine Frage. Wie findet der Debugger den Quellcode passend zur DLL? Kann man irgendwo die SRC Pfade eintragen passend zu den DLLs in irgendwelchen Konfigurationsfiles?

Ich hoffe auf positive Antworten.

Sollte es Unklarheiten geben oder weitere Informationen benötigt werden fragt einfach.

MfG Krümel

//Edit: Eingesetzte Entwicklungsumgebung hier: VS Prof. 2010, und zur Kompilierung(bis auf Debug) MsBuild

Hallo Kruemel,

Wir handeln das bei uns ähnlich;
wir haben unsere oft genutzen dlls auch ausgelagert.

vielleicht hilft dir das hier:
Enable Debugging into external Dll

Gruß, Kruemel

Da haben sich ja zwei krümel gefunden 😉

@KrümelKuchen:

Der Hauptgrund liegt ganz eifnach an der Restriktion des Testzykluses (kein Arbeiten an Code der von der Abteilung getestet wird) und dadurch kommt es einfach zu doppelten Wartungsarbeiten bei Projektmappen.

Benutzt ihr kein Sourcecodemanagement wie TFS, Git, SVN o.ä.?
Das kann man auch für Binaries benutzen.

Und in den Binaries ( *.pdb ) steht der Pfad zum source, wenn also entweder die pdb fehlt oder der Pfad bei dir anders ist, findet er nichts.

Danke für die Antworten schon einmal

Nein wir benutzen leider kein Sourcecodemanagement.
Wir machen das ganze wesentlich trivialer.

Programmierer hat ein Workdir indem das Projekt leigt an dem er arbeitet.
kann in dem treiben was er will, wenn er aber auf den Knopf Release drückt wird kompiliert und die DLLs + Quellcode in die Ordner für die Tester geschoben.

Diese Testen und kompilieren den Quellcode dann über eine Bat Datei und schieben wieder den Quellcode + Programme an die passenden Orte Programmserver + Ordner für freigegebenen SRC.

Aber das mit den PDBs wird dann der Schlüßel sein den ich suche. Dann müssen wir halt die Richtlinien dann ändern das bei der Freigabekompilierung PDB Dateien erstellt werden müssen.
(einfach Ablauf der Freigabe ändern... erst Prod Code sichern, neuen rüberkopieren, dann kompilieren statt kompilieren, sichern, verschieben)
Damit sollte nach meinem jetzigen Verstädniss alles passend laufen, oder sehe ich das nun falsch?

// Zum Managmentsystem
So ein Mangmentsystem wurde einmal getestet aber die Administration meinte, ihnen sei das zu aufwendig zu warten, wer eins fordert meldet sich damit freiwillig zum warten 😃
Das Problem was ich sehe ist das einfrieren des Testcodes.
Restriktion ganz einfach, alle Freigegbenen Programme müssen zu jedem Zeitpunkt so kompilierbar sein.
Meines Wissens hat ja so ein System nur "2" Ebenen.
ServerCode und Workdir
Programmierer reserviert und comitted wenn er fertig ist => Verstoß gegen die Restriktion.

MfG Krümelkuchen

Nein wir benutzen leider kein Sourcecodemanagement.

Echt jetzt? 8o

So ein Mangmentsystem wurde einmal getestet aber die Administration meinte, ihnen sei das zu aufwendig zu warten

Z.B. ein SVN-Server ist in 10min eingerichtet und dann quasi wartungsfrei. Keine Ahnung, wer da was getestet hat, aber ohne Versionsverwaltung ist das ganze enorm aufwendig zu warten.

Meines Wissens hat ja so ein System nur "2" Ebenen. ServerCode und Workdir
Programmierer reserviert und comitted wenn er fertig ist => Verstoß gegen die Restriktion.

Guck dir mal das "trunk, tags, branches"-Konzept an. Es ist nicht so, wie du dir das denkst.

Eine Quellcodeverwaltung ist in meinen Augen ebenfalls einfach zu warten. Und dann würde sich das Debugproblem auch erledigen, da jeder Tester direkten zugriff auf orginalen quellcode hätte (Wenn ich das richtig verstanden habe)

Ach der Server wird mindestens 1 mal täglich gesichert auf den Sicherungsserver. Also so mal mit "weg" ist nicht, wird dann einfach per Mausklick die Spiegelung auf eine neue VM geworfen.

Ausfallzeit ~20 Minuten.

Aber bei einem SVN System habe ich ja eigentlich keine direkten Vorteile, vl habe ich den Sinn dahinter noch nicht ganz verstanden.

SVN System: 1 Verzeichnis am Server auf dem der Quellcode liegt. Die Benutzer haben alle ein Verzeichnis, welches sie aktualisieren können und eine Kopie der Quelldateien in ihrem Workdir haben (einfacher Kopiervorgang). Danach setzen sie ihr Bearbeitungsflag, so dass kein anderer an den Files rumschrauben kann.

Wenn die Arbeit fertig ist wird das Flag entfernt und auf den Server comitted.

Das ist doch grob gesagt ein Sourcecodemanagement System.

Ist relativ analog zu: Entwickler kopiert sich das Projekt was er braucht aus dem Ordner arbeitet daran und schiebt es zu den Testern, oder übersehe ich einen wesentlichen Punkt an dem Managment System?

zur Info: Ich bin nicht grundsätzlich gegen so ein System, bloß müssen Vorschläge und Änderungen begründet und präsentiert werden, bzw einen Wirklichen Vorteil bringen.
Ich pers. meine das die Systeme teilweise zu oft benutzt werden ... Wenn 2 Leute sich nicht absprechen können dann sind dort ganz andere Probleme im Team, anders sieht es aus wenn 15 Leute an einem Projekt sitzen, dann ist es wirklich eine Pflicht.

BTW: back zur Ursprünglichen Frage, reichen dann bei der Kompilierung pdbonly oder müssen alle Debuging Informationen geschrieben werden?

//Edit zur neuen Fragestellung von dir Killerkrümel:
Die Entwickler und Tester haben immer zugang zum Produktiven Quellcode mit Schreibschutz.

Also sieht so aus
Programm arbeitet mit einer DLL zusammen, eine Änderung am Programm ist von nöten.
Der Programierer kopiert sich dann das entsprechende Projekt welches er bearbeiten muss.
(Also nur das 1 Projekt)
Bei Debuggen soll er aber auch in die DLL schauen können. Datenübergabe prüfen was auch immer. (evtl liegt auch der Bug in einem anderem Projekt)
Ist die Arbeit abgeschlossen schiebt er den Quellcode zu den Testern(im gleichen Schritt wird die Version auch kompiliert)
Das Projekt ist nun für die Bearbeitung gesperrt.
Wenn die Tester sagen ja alles in Ordnung überschreiben sie den aktuellen freigegebenen Code und geben somit die Änderung frei.
So wird es derzeit gehandhabt.

Das Problem ist halt derzeit nur das beim Debuggen VS nicht immer den Freigebenen SRC der DLLs gefunden hat.

MfG Krümelkuchen

Hallo,

Nein wir benutzen leider kein Sourcecodemanagement.
Wir machen das ganze wesentlich trivialer.

Haben wir heute den 1. April? Ähmm 8o

Ach der Server wird mindestens 1 mal täglich gesichert auf den Sicherungsserver. Also so mal mit "weg" ist nicht, wird dann einfach per Mausklick die Spiegelung auf eine neue VM geworfen.

Ausfallzeit ~20 Minuten.

Ich bin nicht grundsätzlich gegen so ein System, bloß müssen Vorschläge und Änderungen begründet und präsentiert werden, bzw einen Wirklichen Vorteil bringen.

Dann würde ich dir mal empfehlen dich in die Thematik etwas einzulesen.
http://de.wikipedia.org/wiki/Versionsverwaltung

Ein Vorteil eines verteilten System ist, dass die Ausfallzeit (Zeit, in der ein Programmierer nicht produktiv arbeiten kann) nach einem Serverausfall in der Regel 0. Minuten beträgt.

Hier noch ein paar Links zum verteilten System Git:
http://progit.org/book/de/
http://de.whygitisbetterthanx.com/#git-is-fast

Gruß, Thomas

oder übersehe ich einen wesentlichen Punkt an dem Managment System?

Ja, so ziemlich alles. Wie könnt ihr z. B. Änderungen verfolgen und dokumentieren? Wie stellt ihr eine alte Version her? Wie "mergt" ihr gleichzeitige Änderungen mehrerer Entwickler?

Prinzipiell auf "Projektmappen" verzichten zu wollen, finde ich schon irgendwie "abenteuerlich". Die dienen ja u.a. auch dazu, Abhängigkeiten einzelner Projekte zu handhaben. Kein Versionsmanagement zu benutzen ist allerdings noch schlimmer.

Ja, so ziemlich alles. Wie könnt ihr z. B. Änderungen verfolgen und dokumentieren? Wie stellt ihr eine alte Version her? Wie "mergt" ihr gleichzeitige Änderungen mehrerer Entwickler?

Änderungen werden durch SoftwareBugs bzw Änderungsanträge.
Dort wird jeweils der "Iststand" augenommen und am Ende ein "Jetztstand" protokliert.

Im großen und ganzen ist es der absolute Ausnahmefall das 2 Entwickler am gleichen Projekt arbeiten müssten.

Prinzipiell auf "Projektmappen" verzichten zu wollen, finde ich schon irgendwie "abenteuerlich". Die dienen ja u.a. auch dazu, Abhängigkeiten einzelner Projekte zu handhaben. Kein Versionsmanagement zu benutzen ist allerdings noch schlimmer.

Der Hauptpunkt ist auch noch gegen Projektmappen, wo zieht man einen Strich bei Zurodnungen?
Wir schreiben meist allgemeingültige DLLs, was da heißt eine DLL wird von mehreren Programmen genutzt(Sonst wäre ja der Sinn einer DLL verfehlt). Sollen deswegen alle Projekte in eine Projektmappe?
Das macht relativ wenig Sinn.
Sollte ein Programm (aus welchen Gründen auch immer) eine DLL für sich brauchen, dann bleibt diese natürlich wie die Unit Tests in der gleichen Projektmappe.
Einfaches Beispiel SAP Schnitstelle wird fast überall verwendet, wo ordnet man den Quellcode zu? In das Verwaltungsprogramm für Vertriebler, vl zum PDM system der Konstruktion? Aber die dann alle in einer Projektmappe? die haben evtl nur die Schnitstelle zu SAP gemeinsam.
Das sind Gründe wo wir gesagt haben das ein Verzicht auf Projektmappen ein muss für uns ist. Bzw die Gliederung sehr fein wird das im Regelfall pro DLL eine Mappe wird.

Und da die ganze Software nur Firmenintern genutzt wird ist auch eine Bearbeitung von alten Versionen nicht von nöten sein. Sollte ein Backup einer alten nötig sein haben schonmal 2 Instanzen versagt. (Entwickler + Tester) aber dafür gibts ja Serversicherungen.

In dem Sinne haben wir eig ein Managmentsystem nur was halt nicht mit einem seperaten System läuft sondern mit trivialen Lösungen.

Aber ich werde mich trotzdem mal in die Links und Systeme einlesen
Danke für die Links.

LG

BTW: back zur Ursprünglichen Frage, reichen dann bei der Kompilierung pdbonly oder müssen alle Debuging Informationen geschrieben werden?

As far as i know reichen die pdb dateien in verbindung mit den dlls, um durch auf dem quellcode server liegenden dlls zu debuggen.

Gruß, killerkruemel

Also Ich glaube ich habe nun eine vernünftige Lösung gefunden.

Für all jene die mit der ca gleichen Problemstellung konfrontiert werden.

(besonderer Dank an KillerKrümel für seinen Link)

Es schaut nun wie folgt aus:

Quellcode und Programme wie gewohnt getrennt. Die .pdb Dateien liegen aber nicht bei den DLLs sondern in einem seperaten Verzeichnis. (Der Sauberkeit halber)

Dieses Verzeichnis wird wie im Link beschrieben in den Optionen (Symbol) den Pfad zu dem Ordner eingetragen. Nun findet der VS ohne Probleme den SRC Code zu den DLLs.

Einzig wichtig ist noch die Anmerkung das die PDB dateien dorthin verweisen wo sie kompiliert wurden => Eine Kompilierung von einem lokalen PC im Team ist damit nicht gerade empfehlenswert 😃

Danke für die Hilfe und die Aufklärungen.

Mit freundlichen Grüßen
Krümelkuchen