c# - ソリューション出力ディレクトリ

Question

私が現在取り組んでいるプロジェクトは、複数のチームによって開発されており、各チームはプロジェクトのさまざまな部分を担当しています。彼らは皆、独自のニーズに固有の構成設定を使用して、独自の C# プロジェクトとソリューションをセットアップしています。ただし、ここでは、すべてのプロジェクトを結合して同じ出力ディレクトリにビルドする別のグローバル ソリューションを作成する必要があります。

私が遭遇した問題は、すべてのプロジェクトを同じ出力ディレクトリにビルドする方法が 1 つしか見つからなかったことです。それらすべての構成を変更する必要があります。それは私たちが避けたいことです。これらすべてのプロジェクトが、この「グローバル」ソリューションについての知識を持たないようにしたいと考えています。各チームは、独自のサブソリューションだけで作業する可能性を保持する必要があります。

考えられる回避策の 1 つは、この「グローバル」ソリューションのためだけにすべてのプロジェクトに特別な構成を作成することですが、この構成設定をその特定のチームが使用する通常の構成設定と常に同期する必要があるため、追加の問題が発生する可能性があります。私たちが最後にやりたいことは、開発者が構成をチェックインしたが、グローバル構成でそうするのを忘れたという理由だけで、グローバルソリューションの下で構築するときに何かが機能しない理由を理解するのに何時間も費やすことです.

したがって、簡単にするために、そのグローバルで包括的なソリューションからビルドする場合にのみ存在する、ある種の出力ディレクトリ設定またはビルド後のイベントが必要です。プロジェクト構成で何かを変更せずにこれを達成する方法はありますか?

更新 1
私が言及する必要があると思われるいくつかの追加の詳細:

このグローバル ソリューションは、エンド ユーザーがアプリケーションをインストールしたときに得られるものにできるだけ近づける必要があります。これは、アプリケーションのどの部分が機能していないかを把握する必要がある場合に、アプリケーション全体のデバッグに使用する予定であるためです。このバグをその部分に取り組んでいるチームに送信する前に。

これは、グローバル ソリューションでビルドする場合、出力ディレクトリ階層は、インストール後の Program Files と同じにする必要があることを意味します。たとえば、によって開発されたすべてのアドインを含む Program Files/MyApplication/Addins フォルダーがある場合チームが異なるため、アドイン プロジェクトからバイナリをコピーし、それに応じて出力ディレクトリに配置するためのグローバル ソリューションが必要です。

問題は、アドインを開発しているチームは、それがアドインであり、そのフォルダーに配置する必要があることを必ずしも認識していないため、相対的な出力ディレクトリを build/bin/Debug/Addins に変更できないということです。

Answer 1

ここで重要なのは、チームが成果物に責任を持つということです。その成果物はバイナリのコレクションです。したがって、「グローバル」ソリューション...または「チームからの成果物を使用する製品」は、すべての「現在の成果物」が連携して機能することを保証することに関心があります。つまり、共同作業からの成果物があるということです。

したがって、これにはいくつかの質問があります。チームは、「リリース」と見なすものを提供しますか。これは、ビルドシステムでは自動的に行われる場合があります。ビルドしてすべてのテストに合格したら、公開します。

あなたが探しているのは、リリースを公開または宣伝するチームです。ソースコードはそこにたどり着いた方法であり、バイナリは結果です。各チームは、リリースと見なすバイナリを制御します（これはビルドシステムによって自動化される場合があります）。

正確にはあなたが尋ねたものではありませんが、良い結果を出すための正しい質問につながる答えであることを願っています。

Answer 2

非常に簡単な方法の1つは、ソリューションを作成することです。すべてのプロジェクトを含め、プロジェクト（またはそれ以上）を追加して、グローバルソリューションビルドタスクを処理します。グローバルソリューションのプロジェクトは、必要なプロジェクトへの参照を持ち、VisualStudioに各プロジェクトからバイナリを取得する方法を処理させる必要があります。それらは（通常の状況では）ビルドプロジェクトの出力フォルダーにコピーされます。したがって、グローバルビルドタスク用に特別に追加されたプロジェクトには、参照されているすべてのプロジェクトのコピーが含まれます。

もう1つの方法は、残りのビルドスクリプトを参照するグローバルMSBuildスクリプトを作成することです。各プロジェクトには、独自のMSBuildスクリプトがあります

編集

コメントから、プロジェクトには2つのカテゴリーがあるように思われます。構築が必要なものとそうでないもの。

ビルドが必要な場合は、それらを集約プロジェクトのプロジェクトとして参照し、ビルドが不要な場合は、参照として追加するか、リソースとしてdllを追加します。

後者を使用して、ビルドアクションのプロパティを[なし]に変更し、出力ディレクトリにコピーして[新しい場合はコピー]に変更します

どちらの場合も、すべてのdllが出力ディレクトリにあるので、特定のフォルダ（つまり、出力フォルダではない）にあるはずのdllを移動する集約プロジェクトでビルド後のアクションを実行できます。

Answer 3

バージョン管理システムを使用しているかどうかについては言及していません。*.suo または *.user ファイルをチェックしないため、個人的な構成のほとんどは個々のチームメンバーにのみ影響するため、各開発者は自分のチーム構成を維持し、そこのマシンでローカルにビルドすることが実際にわかっています。

完全に別のマシンで、すべてのリポジトリから同じコードをチェックアウトし、ビルド マシンでプロジェクトをコンパイルします (これは完全に自動化できます)。これにより、ビルド サーバーの独立性が維持されます。

それが「解決策」であることを心配しないでください。複数のソリューションを次々に簡単に構築できます。

出力パスは相対 (おそらく "bin\Debug") であるため、チェックアウトした場所にビルドされます。すべてのバイナリを同じ出力フォルダーに入れたい場合は、すべての構成の出力パスを調整して一致させることができます。「....\bin\Debug」のようなもの (明らかに、これはプロジェクトがローカル マシン上でビルドされる場所に影響しますが、問題にならない場合があります)。そうすれば、複数のプロジェクトが同じターゲット出力でビルドされます。

最終製品をパッケージ化するために、各開発者のローカル マシン上にないビルド サーバーに別のセットアップ ビルドを含めることもできます。

Answer 4

継続的インテグレーションの実践と、スクリプト化されたビルドでのビルド サーバーの使用法をご覧ください。これは、チームとしてアプリケーションのさまざまな部分を開発する際に不可欠なツールであり、問​​題はその理由をよく表しています。