Visual Studio C＃ソリューションでは、すべてのプロジェクトで同じ出力パスを共有するのに不利な点はありますか？依存関係注入を使用し、ファイルが（参照されていないので）自動的にコピーされないため、私はこれを実行したいと思います。これは私に何か問題を引き起こすでしょうか？C＃ - すべてのプロジェクトが同じ出力パスを共有するという欠点はありますか？
（これはに関連している：C# - Copy dlls to the exe output directory when using dependency injection with no references?）
我々は、我々の現在のプロジェクトにこれをやっています。同じbinフォルダに約30件のプロジェクトが出力されており、問題はありませんでした。
複数のプロジェクトを持つことのポイントは、複数のアセンブリを生成することです。アセンブリは.Netの配備メカニズムです。すべての出力dllを1つのパッケージにバンドルする予定がある場合は、このアプローチでは不利な点はありません。
しかし、アセンブリーD、E、Fとは別の理由でアセンブリーA、B、Cを別々に配備する場合は、出力ディレクトリーを別々にしておくことで、正しいアセンブリーとその依存関係のみが出力フォルダ。これらのアセンブリを必要な正しいパッケージに正しくバンドルするスクリプトを作成する方が簡単です。
一般的に不利ではありませんが、ターゲットアセンブリの出力場所を1つにすることは非常に有益です。 VSが依存関係を判断してコンパイルするプロジェクトをソートすると、ビルド順で先にビルドされた既存のコンパイル済みアセンブリのインスタンスが上書きされます。
すべてがビルドされているときに、コンパイルされたアセンブリのために巡回する必要がありません。あなたは、異なるバージョンのものであり、外部アセンブリへの参照を持つ2つのプロジェクトを持っている場合は、問題が発生する可能性があり
いくつかのインスタンスがあり、あなたは...依存関係の誤ったバージョンせずにバンドルされてアセンブリに終わる可能性があり
同じアセンブリの異なるバージョンに応じて2つの異なるプロジェクトがある場合は、潜在的な問題があります。 X.dllバージョン1に応じてプロジェクトAを、X.dllバージョン2に応じてプロジェクトBを使用すると、X.dllの両方のバージョンを同じ出力フォルダに置くことはできません（名前を変更せずに） 。確かに、これらの可能性は高くはありませんが、ゼロではありません。あなたはさまざまな方法であなたのアセンブリを展開を計画している場合は、/ TeamBuildまたは使用しているものは何でも自動ビルドプロセスワットの問題に遭遇することがあり
（コアパッケージ対など、アドオン）
かをカスタマイズする方法csprojファイルに対するカスタマイズの程度に応じて、ビルドスクリプトが異なる（必ずしも不利であるとは限りません）。
copy local = falseであっても、スタートアッププロジェクトでビルド中に他のプロジェクトが参照しているdllへの参照が保持されていると、アクセス違反の問題が発生することがよくあります。私は毎日この問題にぶつかります。私は必要なすべての参照を持つプロジェクトを持っていることを示唆し、それらの参照のためにlocal = trueをコピーすることをお勧めします。これはインストーラの作成にも役立ちます。