2017-03-09 9 views
0

ソリューション内のいくつかのプロジェクトが別のソリューションの別のプロジェクトのアセンブリへの参照を作成する複数のソリューションを使用する場合に最適な方法は何ですか?例えばVisual Studio 2015複数のソリューション戦略(TFS)

- Solution 1 
-- Proj1 
-- Proj2 
- Solution 2 
- OtherProj 1 
- Solution 3 
- FooProj1 
- FooProj2 

OtherProj、FooProj1とFooProj2はPROJ1又はProj2アセンブリを使用する場合。

今度はProj1をビルドし、そのアセンブリをソリューション2とソリューション3のソリューションフォルダに手動でコピー/ペーストする必要があります。 ローカルパスを使用し、チェックインすると直接参照できませんソースコントロール(TFS)を介して、私の同僚は自分のローカルパスを受け取ります(つまり、ソリューションのフォルダにコピー&ペーストしてパスが常に相対的になるのです)。

ポストビルドイベントを追加し、アセンブリをserver \ myserver \ assemblies \ relaase \ Proj1.dllの共有フォルダにコピーして、ソリューション/プロジェクトのこれらのファイルを参照することを考えました。

これはソースコントロールでも機能するため、良い戦略ですか、それとも他の戦略がありますか?

(何かは、Visual Studioでの共有プロジェクトのように存在しているが、私はそれが周りに共有するのではなく、単一のソリューションが、複数のプラットフォームのためのより多くのだと思う)

+0

コードベースが十分に大きくなると、単一のSLNファイルが管理不能になります。その時点で、すべてのプロジェクトを正しい順序で構築するために、MSBUILDの ".proj"ファイルを作成して管理する必要があります。これを行うと、プロジェクトはビルドされた場所からDLLを参照できます。参照には絶対パスを使用する必要はありません。相対パスを使用する必要があります(別のアセンブリへの参照を作成する際のデフォルトですので、ここで特別な処理を行う必要はありません)。 –

答えて

2

あなたはNugetパッケージとして各プロジェクト/ソリューションの出力を公開する必要がありますそれらのパッケージに依存しています。

ほとんどの機能を組み込んだNugetパッケージとしてパッケージ化されたプロジェクトやソリューションの出力は非常に簡単です。NuGetリポジトリはネットワーク共有でも、ホストサービス(MyGet、VSTS/TFS、その他)。

+0

Nigetパッケージの公開はCIビルドでは問題ありませんが、SolutionAを参照する別のソリューション(SolutionB)で作業しているときに、あるソリューション(SolutionA)を変更する必要はありますか?ソリューションBのNugetパッケージリファレンスを一時的にローカルリファレンス(ネックの痛みとそのローカルリファレンスの偶発的コミットの影響を受ける)と一時的に置き換える以外に、他にどのようなオプションがありますか? –

+0

各ソリューションは、疎結合のサードパーティパッケージとして扱います。あなたが書いているのは、コードの緊密な結合です。良い練習ではありません... –

+0

これはカップリングとは関係ありません。同時に、ライブラリとそのライブラリを使用するアプリケーションなど、同時に開発している開発と関連しています。ライブラリ内で変更を加え、アプリケーションですぐに参照/使用する必要があります。 Nugetリポジトリへの公開は大惨事であり、NugetがMavenのSNAPSHOTバージョンに類似したものをサポートしていない場合は辛いです。 Nugetがそれを持っていれば、少なくともすべてのビルドで図書館を公開することは可能です。 –

0

VSエクステンションNuGetリファレンススイッチャーは、この状況の1つの解決方法です。その説明から:

NuGet Reference Switcherは、NuGetアセンブリ参照をプロジェクト参照に自動的に切り替えるVisual Studio拡張機能で、その逆も同様です。これは、独自のNuGetパッケージを参照するアプリケーションを開発する場合に便利です。

Here is the VS 2015 version

Here is the VS 2017 version

関連する問題