| 

.NET C# Java Javascript Exception

1
In diesem Thread werden zwei Varianten diskutiert, WIE man für alle Projekte einer VS-Solution ein gemeinsames Ausgabeverzeichnis einrichten kann. Ich möchte hier die Frage aufwerfen, OB das überhaupt nützlich bzw. eine gute Idee ist.

Ein Argument dafür könnte sein, dass die DLL von einem häufig referenzierten Projekt nur noch einmal auf der Platte liegt (jedenfalls bei einer der beiden in besagtem Thread diskutierten Varianten) und nicht im Build-Ordner jedes einzelnen referenzierenden Projekts (ich hatte schon Solutions mit über 50 Projekten, das läppert sich zusammen) - spart Plattenplatz und Build-Zeit, weil weniger kopiert werden muss.

Ein mögliches Argument dagegen: Microsoft wird sich doch was dabei gedacht haben, oder???
News:
17.02.2011
Matthias Hlawatsch 13,2k 4 9
Bloß weil Microsoft etwas auf eine bestimmte Art und Weise vorsieht, muss es nicht gut sein ... ich sag nur "DB-Tabelle aus dem Server Explorer direkt auf eine Form ziehen" ... auch das sieht für einen absoluten Anfänger nett und einfach aus, aber dass es keine gute Idee ist, darüber brauchen wir glaube ich nicht zu reden ;-).
Golo Roden 17.02.2011
PS: Ich wollte damit nicht ausdrücken, dass ich Dich für einen absoluten Anfänger halte - falls das so klang, so war es nicht gemeint!
Golo Roden 17.02.2011
Ist schon richtig angekommen ;-) Und ich lese dass dann auch so, dass Du wie die anderen Antworter die Idee prinzipiell für sinnvoll hältst. Deine Meinung zu dem Für und Wider der beiden Optionen in dem verlinkten Thread würde mich übrigens auch interessieren...
Matthias Hlawatsch 19.02.2011
@alle: vielen Dank für die Antworten und die verschiedenen Aspekte, die ihr beleuchtet habt. Das Argument von Gentlehag war für mich das schwerwiegendste, aber die anderen halte ich ebenso für gültig und hilfreich.
Matthias Hlawatsch 19.02.2011
3 Antworten
4
Wir haben es so strukturiert.
Bei uns sind anwendungen in einzelne Komponenten aufgeteilt, welche wiederrum in einzelnen DLL's liegen.
Alle Komponenten / Projekte einer Domaine builden sich in ein Verzeichnis.
Wenn man nun eine neue Komponente erstellt, welche bestehende komponenten braucht verweist sie diese von dort.

Für uns erleichtert es das management.
Wir unterscheiden noch zwischen einem verzeichnis für Assemblies von Fremdhersteller und eins von eigenen Projekten.

Würde sich alles in die Standard ordner builden wären die verweise nicht praktikabel. würde man z.bsp. die konfig von debug auf release ändern , würden andere projekte, ja immer noch die debug dlls verweisen, das wäre sehr unschön.
17.02.2011
Gentlehag 1,0k 2 8
Wir machen das auch so. Das bequeme Umschalten von Debug zu Release gab den Ausschlag. So kann man auch ausgewählte Komponenten als "Debug" übersetzen und den Rest so lassen.
ralf.w. 17.02.2011
Ich nehme mal an, dass dieses Szenario für den Fall gilt, dass die Projekte für zwei Komponenten, von denen die eine die andere referenziert, in unterschiedlichen Solutions hängen? Sonst könnte man ja einfach eine Projektreferenz verwenden. Wie macht ihr das mit den unterschiedlichen Build-Konfigurationen? In dem großen Build-Ordner sollten ja die Debug- und Release-Version möglichst immer beide auf dem gleichen Stand sein?
Matthias Hlawatsch 17.02.2011
Ja genau.
Im allgemeinen kann man sagen dass bei mir eine Solution eine Komponente ist.

Im Regelfall ein Interface Projekt, die standard implementierung und die BlackBox Unit Tests.

Gentlehag 17.02.2011
2
Abgesehen vom Plattenplatz und von der Zeitersparnis weil zusätzliche Kopiervorgänge vermieden würden, kann das doch sogar sehr praktisch sein. Wenn es z.B. darum geht einer Gruppe von Personen Zugang zu allen Binaries/PDBs etc. zu gestatten aber eben nicht zum Sourcecode wäre das ja viel einfacher zu bewerkstelligen.
Außerdem hätte man ja quasi ohne Mehraufwand einen fertigen Ordner für's XCOPY-Deployment, ohne dass noch ein Script erstellt werden muss, dass erst wieder alle Projekte abklappert und die Dateien kopiert.
Die von Microsoft gewählte Voreinstellung würde ich nicht unbedingt als Gegenargument werten, denn sie verhindern eine solche Änderung ja nicht explizit. Ganz im Gegenteil ist diese Änderung ja nicht nur mit Tricks unter der Haube zu bewerkstelligen, sondern sogar GUI-Bestandteil der Build-Einstellungen in VS.
17.02.2011
Torsten Weber 691 1 8
Das erste und dritte Argument leuchten mir ein. Den fertigen Ordner für XCopy habe ich doch aber auch so: der Build-Ordner der Exe-Datei, der ja auch alle referenzierten DLLs enthält. Oder?
Matthias Hlawatsch 17.02.2011
Da hast Du schon recht, ja. Nehmen wir aber mal an, Du hast ein Skript was alle Artefakte komprimieren und irgendwohin uploaden soll. Wenn alle Projekte in einen Ordner ausgeben, muss das Skript die einzelnen Projekte nicht kennen, sondern nur diesen einen Pfad rekursiv bearbeiten. Wenn neue Projekte hinzukommen oder Projekte aus der Solution entfernt werden müsste das Skript nicht angepasst werden.
Torsten Weber 17.02.2011
1
Wir hatten vor etwa zwei Jahren ein großes Projekt in Entwicklung: Viele einzelene Solutions für die Komponenten plus Exe. Die Assemblies mussten nach dem Build via Service signiert werden und für den Test in eine gemeinsame Verzeichnisstruktur unter C:\Program Files\ kopiert werden.

Wir haben Postbuild Steps verwendet um die Dateien zu signieren und in das Zielverzeichnis zu kopieren.

Manchmal hat jedoch VS die Dateien im Zielverzeichnis gesperrt und konnte den Postbuild Step nicht durchführen. Da half nur VS beenden und neu starten.

Wenn aber wie bei uns monatlich Updates installiert werden, und auch die in Entwicklung befindliche Anwendung mit ihren Komponenten auf die Developer PCs deployed wird, werden diese Dateien natürlich überschrieben.

Das ist leider bei uns der Fall.

Dafür gibt es für jede Version der Komponenten Setup Pakete auf einem Netzlaufwerk sowie ein "Aktuell" benanntes Setup, das den zuletzt eingecheckten und wöchentlichen Build enthält. Diese müssen die Devoloper dann für jede Komponente wieder ausführen. Aber auch das haben wir mittlerweile automatisiert.

Fazit: In großen Projekten wird man an so einer Lösung nicht vorbei kommen, es entsteht u. U. dadurch organisatorischer Overhead und erfordert viel Disziplin.
17.02.2011
Maria Simlinger 1,1k 1 9
1
kann ich nur bestätigen. In diesem Zusammenahng ist auch ein automatisierter Buildprozess sehr wichtig.
Gentlehag 17.02.2011

Stelle deine Visual-studio-Frage jetzt!
TOP TECHNOLOGIES CONSULTING GmbH