プロジェクトの参考資料v NuGetの依存関係

Question

外部のバイナリ（Moq、NUnitなど）と共有機能を含む内部ライブラリプロジェクトの両方で、ソフトウェア開発プロセスにNuGetを導入しています。

TeamCityは、私たちの内部ライブラリプロジェクトからNuGetパッケージを生成し、それらをローカルリポジトリに公開しています。変更されたソリューションファイルは、NuGetパッケージにアクセスするためにローカルリポジトリを使用します。

次のソースコードのソリューションを検討します。

1. Company.Interfaces.slnはCompany.Interfaces.1.2.3.7654.nupkgを構築します。
2. Company.Common.slnはNuGetパッケージを介しCompany.Interfacesへの参照が含まれ、そしてCompany.Interfaces.1.2.3.7654が依存として含まれると、Company.Common.1.1.1.7655.nupkgを構築します。
3. Company.DataAccess.slnは、Company.Common nupkgを使用して Company.InterfacesおよびCompany.Commonを参照として追加します。これは、従属コンポーネントとしてCompany.Common.1.1.1.7655を含む Company.DataAccess.1.0.8.7660.nupkgを構築します。
4. Company.Product.Aは、すべての3つのライブラリプロジェクト（ Company.DataAccess NuGetパッケージを選択して追加）を参照するWebサイトソリューションです。

質問：

Company.Interfacesにソースコードの変更がある場合は、私はいつも、パッケージの番号を変更し、中間パッケージ（Company.CommonとCompany.DataAccess）を再構築し、更新する必要がありません会社。製品.A？

やソースコードの変更は、バグ修正、または

新機能、または

破壊変更

• であったかどうかに依存していますか？

実際には、8レベルの依存ライブラリパッケージがあります。パッケージのツリー全体を更新するためのツールサポートが必要ですか？

私はセマンティックバージョン管理について知っています。

VS2012、C＃4.0、TeamCity 7.1.5を使用しています。

Answer 1

早期にテストするために、各チェックインのすべてを更新することをお勧めします。

アーティファクトの依存関係（http://confluence.jetbrains.com/display/TCD7/Artifact+Dependencies）とビルドの完了ビルドトリガー（または「Nuget Dependency Trigger」のみ）を使用して簡単に管理できます。

Answer 2

私たちは独自のビルド構成を基本プロジェクトに書いています（Company.Interfacesです）。この場合、sln）、ツリー全体を一度に構築して更新します。途中で更新されたpackages.configファイルと.nuspecファイルをチェックインします。私はたとえそれが最初に過度のように聞こえるかもしれないとしても、これがどれだけ時間を節約してくれたかは、私たちのために終わったとは言えません。

私たちが書いたスクリプトは、チェーンが途中で失敗してもファイルをチェックし、ローカルマシンで修正する可能性を与え、修正をチェックして公開を再開します。