2

既定では、Visual Studio (2010 および 11 ベータ版) は、ソリューション内のすべてのプロジェクトを個別のフォルダーにビルドします。その結果、特にプロジェクトが相互に参照している場合、ビルド中にかなりの量がコピーされます(CopyLocal = true):

-- 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

私の現在のソリューションには 90 個のプロジェクトがあり、そのうちの大多数が相互に少なくともいくつかの参照を持っているため (実際の実行可能ファイルは 3 つだけです)、これは非常に面倒であり、デフォルトで Visual Studio が配置しないのはなぜなのか疑問に思っていました。すべてのプロジェクト出力が同じフォルダーに保存されますが、代わりにこの恐ろしい冗長性が発生します。出力フォルダーを変更して参照プロジェクトのコピーをオフにできることは承知していますが、デフォルトの動作の背後に理由があるかどうかを知りたいです。

VS2005 はデフォルトですべてを 1 つのフォルダーに入れますが (2008 については不明)、実際に不利な点はありましたか? また、VS10 (おそらく VS アドオン) で、すべてのプロジェクトの出力フォルダーを同じフォルダーに設定CopyLocal = falseし、各プロジェクト参照を設定する方法はありますか?

4

1 に答える 1

2

私が考えることができることの1つは、プロジェクトを互いに分離することです。つまり、1つのプロジェクトを変更（およびコンパイル）しても、変更を処理するために適切に更新されていない他のプロジェクトはすぐには壊れません。

すべてが1つのフォルダーにある場合、上記のシナリオは（ソリューション全体を再構築するまで）不必要な頭痛の種を引き起こす可能性があります。

于 2012-04-10T10:24:54.940 に答える