ナゲットで複数のソリューションを使用する開発プロセス

Question

複数のソリューションで構成され、それぞれのソリューションがローカルのナゲットサーバーに公開されるリポジトリを作成したいと考えています。

しかし、ソリューションAを編集し、ソリューションAをナゲットパッケージから参照する別のソリューションBを使ってテストするときに、開発プロセスをどのように行うのか分からないのは、それぞれのビルド後にソリューションAを公開することです。私がソリューションBでプロジェクトのリファレンスを作成すると、それは適切な依存関係をもたらし、私はそれを望んでいません。

私はソリューションBにいくつかの機能を追加したいと思います。ソリューションAを変更する必要があります。ソリューションBはソリューションAへのナゲットリファレンスを持っています。ソリューションAを変更すると公開する必要がありますナゲットサーバーに更新し、ナゲットサーバーの更新まで待つだけで、ソリューションBでテストすることができます。

私が必要とする質問の答え： 私たちはマイクロサービスを構築しており、それぞれのマイクロサービスを別々のソリューションとそれぞれの共有ライブラリをスタンドアロンソリューションで開発することに決めました。そして、このすべての複数のソリューションを持つ1つのリポジトリ:-)

Answer 1

開発プロセスにおけるnuget

で

NuGetは、Microsoftの開発プラットフォーム用のパッケージマネージャとして多くの利点がありますが、それはそれはある意味ではありません欠陥がない。遭遇したのと同じように、参照プロジェクトが頻繁に変更された場合は、再構築し、nugetパッケージを作成し、nugetサーバーに公開し、変更ごとにnugetサーバーが更新されるまで待つ必要があります。それは退屈な仕事をたくさんもたらすでしょう。この欠点を解決するには、Project-to-projectの参照がより良い方法である必要があります。だから、サムとアイメマックの提案が推奨されるはずです。

プロジェクトツープロジェクト参照の利点は、ビルドシステムのプロジェクト間に依存関係を作成することです。依存プロジェクトは、参照プロジェクトが最後に作成されてから変更された場合に作成されます。ファイル参照はビルド依存関係を作成しないため、依存プロジェクトを構築せずに参照プロジェクトをビルドすることは可能です。

ので最適なソリューション参照プロジェクトが頻繁に変更されたときにプロジェクト間の参照をお勧めしなければならないということで、nuget参照は、他の人に参照プロジェクトを共有したり、それを公開するときに、より適切です。ちょうどNuGet Reference Switcherのように。