| 

.NET C# Java Javascript Exception

3
Warum ist welche Option besser?

1. In den Projekteinstellungen den Output path aller Projekte auf ein Buildverzeichnis legen

oder

2 Mit einem Post-build event vom Projekt /bin Ordner in das gemeinsame Buildverzeichnis kopieren
News:
16.02.2011
KCT 937 1 8
4 Antworten
1
Wenn du nur Dateien kopieren willst, dann würde ich dir Option 1 empfehlen.
Jedoch ist zu beachten, dass du für jede Build-Konfiguration ein eigenes Output-Verzeichnis hast, dass heißt du müsstest deine Einstellungen für jede Konfiguration übernehmen.

Vordefiniert sind hier ja Debug (bin/Debug) und Release (bin/Release).

Im PostBuildEvent könntest du dass Problem aber umgehen in dem du die bereitgestellten Macros verwendest.
Mit denen könntest du dann Dateien vom jeweiligen eingestellten OutDir in das gewünschte Verzeichnis kopieren.

copy "$(TargetDir)*.*" "C:\output"


Was bei den PostBuildEvents aber zu beachten ist, ist dass du selbst sicherstellen musst, dass das Verzeichnis bereits erstellt wurde. Der Ausgabepfad in der Build-Konfiguration wird automatisch erstellt.

if not exist "C:\output" mkdir "C:\output"
copy "$(TargetDir)*.*" "C:\output"
16.02.2011
woni 170 1 4
Da ich doch sowieso in den Einstellungen bin da dauert ein beherztes Copy & Past nicht lange den gleichen Pfad nur mit /Release bzw /Debug am Ende in jede Konfiguration zu kopieren. So denn ich weitere Einstellungen vornehmen muss in Debug und Release spielt es eigentlich keine Rolle mehr.
KCT 17.02.2011
1
Gute Frage!

Hat mich dazu gebracht zu überlegen, ob/warum man das überhaupt machen sollte. Ich habe dazu eine eigene Frage gestellt, damit es hier nicht zu unübersichtlich wird.

Zu Deiner Frage: ein Unterschied zwischen den beiden Varianten ist auf jeden Fall, dass ich in Version 1 die DLLs nur im gemeinsamen Output-Ordner habe, in Version 2 hingegen sowohl separat pro Projekt in den jeweiligen bin-Ordnern und zusätzlich im gemeinsamen Verzeichnis. Mal abgesehen von Plattenplatz und Build-Zeit fürs Kopieren könnte dieser Unterschied auch wichtig sein, wenn später mal noch ein Setup-Projekt hinzukommt, das aber nur einen Teil der anderen Projekte verwenden soll (sprich: manche DLLs sollen außen vor bleiben). Wenn ich mich recht erinnere, greift ein Setup-Projekt nämlich auf das Output-Verzeichnis der anderen Projekte zu. Wenn es nur ein gemeinsames gibt, könnte eine Differenzierung schwierig werden
17.02.2011
Matthias Hlawatsch 13,2k 4 9
Für den Fall einer Einzelanwendung, die nicht Frameworks einzeln bereitstellen soll und insbesonder bei vielen Assemblies, also noch ein Pluspunkt für Option 1. Bisher sieht es so aus, dass Option 2 ehr der "seltenere" Fall zu sein scheint.
KCT 17.02.2011
1
Du schreibst leider nicht um welche Art Anwendung es sich handelt.

1. Wenn es sich um eine Web-Anwendung handelt würde ich die Deploy-Funktion von VS.NET nutzen um die erforderlichen Dateien in das Zielverzeichnis zu bringen.

2. Bei Windows Anwendungen würde ich die Postbuild Steps dann verwenden, wenn noch zusätzliche Schritte wie z. B. Signieren o. ä. nötig sind. Beispiel aus meiner Erfahrung:

Wir haben in einem großen Projekt (vor ca. zwei Jahren mit VS.NET 2005) Postbuild Steps verwendet um die Dateien zu signieren und in ein bestimmtes Zielverzeichnis zu kopieren. (Viele einzelne Solutions, eine Exe, die auf das Zielverzeichnis referenziert hat).

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.

3. Wenn du die Dateien im bin Verzeichnis der Solution nicht benötigst, dann setze den Output Pfad um.
17.02.2011
Maria Simlinger 1,1k 1 9
1
Es ging mir darum generelle Best Practices zu finden wann was am Besten ist. Daher war es mir bisher nicht wichtig welche Anwendung es ist.

Zu 2: Interessanter Hinweis.
KCT 17.02.2011
0
Lustigerweise ist es just heute geschehen, dass wir nicht nur mit den Konfigurationen Debug und Release kompilieren müssen, sondern auch noch die Unterscheidung für 32 und 64 bit berücksichtigen sollen. Jetzt wäre es natürlich schon den Post-build Event zu haben :-)

Somit fasse ich bisher zusammen:

Gemeinsames Verzeichnis:
+ schneller, da nicht mehr kopiert werden muss
- einmaliger Konfigurationsaufwand für neue Buildkonfigurationen

Post-build Event Copy:
+ weniger Aufwand in den Projekteigenschaften wenn unterschiedliche Build-Konfigurationen benötigt werden (insb. wenn eine Konfiguration im nachhinein hinzu kommt)
+ nötig wenn zusätzliche Schritte benötigt werde wie z.B. signieren
+ ggf. nötig wenn Assemblies unterschiedlich verteilt werden sollen
- langsam, da zusätzlich kopiert wird
17.02.2011
KCT 937 1 8

Stelle deine Event-Frage jetzt!