1

Visual Studio (2010 sowie 11 Beta) erstellt standardmäßig jedes Projekt in einer Lösung in einem separaten Ordner.Gibt es einen Grund, warum Visual Studio jedes Projekt in einem separaten Ordner ablegt?

-- solution has four projects: proj1, proj2, proj3 and proj4 
-- building proj1 -- 
solution/proj1/bin/debug/proj1.dll 
-- building proj2 (depends on proj1) -- 
solution/proj2/bin/debug/proj1.dll 
solution/proj2/bin/debug/proj2.dll 
-- building proj3 (depends on proj1) -- 
solution/proj3/bin/debug/proj1.dll 
solution/proj3/bin/debug/proj3.dll 
-- building proj4 (depends on proj2 and proj3) -- 
solution/proj4/bin/debug/proj1.dll 
solution/proj4/bin/debug/proj2.dll 
solution/proj4/bin/debug/proj3.dll 
solution/proj4/bin/debug/proj4.dll 

Da meine aktuelle Lösung hat 90 Projekte, von denen die Mehrheit zu einer zumindest ein paar Referenzen haben: Als Ergebnis, vor allem, wenn die Projekte aufeinander verweisen, werden sie um eine ganze Menge während Build (CopyLocal = true) kopiert ein anderes (nur 3 sind tatsächliche ausführbare Dateien), das ist ziemlich ärgerlich und ich habe mich gefragt, warum Visual Studio standardmäßig nicht jedes Projekt in den gleichen Ordner legt, sondern stattdessen diese schreckliche Redundanz verursacht. Ich bin mir bewusst, dass ich den Ausgabeordner ändern und das Kopieren von referenzierten Projekten deaktivieren kann, aber ich würde gerne wissen, ob es eine Begründung für das Standardverhalten gibt.

VS2005 legt alles standardmäßig in einen Ordner (nicht sicher über 2008), aber hatte das tatsächliche Nachteile? Gibt es auch eine Möglichkeit in VS10 (VS Addon vielleicht), den Ausgabeordner für alle Projekte auf den gleichen Ordner zu setzen, sowie die Einstellung CopyLocal = false für jede Projektreferenz?

+1

Es ist eine einfache Möglichkeit, Dateinamen Kollisionen zu vermeiden. Nicht so sehr im bin \ Debug Ordner, definitiv im obj \ Debug Ordner. –

+0

@HansPassant Guter Punkt, jedoch ist das Zwischenverzeichnis unabhängig vom eigentlichen Ausgabeverzeichnis. Selbst wenn das Ausgabeverzeichnis geändert wird, ist der obj-Ordner für jedes Projekt noch separat, was in der Tat Sinn macht. – dialer

Antwort

1

Eine Sache, die ich mir vorstellen kann, ist, die Projekte voneinander zu trennen, das heißt: Wenn Sie ein Projekt ändern (und kompilieren), werden nicht sofort andere Projekte unterbrochen, die nicht richtig aktualisiert wurden.

Wenn alles in einem Ordner ist, kann das obige Szenario unnötige Kopfschmerzen verursachen (bis Sie die gesamte Lösung neu erstellen).

+0

Macht in der Theorie Sinn, aber sagen Sie haben eine dll und eine exe, und Sie ändern die DLL und führen die exe, VS wird Sie trotzdem warnen, dass die Lösung veraltet ist und neu erstellt werden muss. - Wenn Sie eine brechende Änderung an der DLL vornehmen, die nicht durch eine einfache Neuerstellung gelöst wird, könnten Sie theoretisch unabhängig an Modulen arbeiten, aber dafür sind Schnittstellen und mehrere Lösungen gedacht, da in diesem Fall die exe geändert/neu erstellt wird wird immer noch alles kaputt machen. – dialer

+1

Ich dachte eher an das, was passiert, wenn Sie das Programm außerhalb von VS ausführen – Attila

Verwandte Themen