3

構築/保守する製品の数が多いため、かなり複雑なdll構造（> 100アセンブリ）があります。現在、TFS 2012をインストール中です。現在、NuGetを使用して外部dllへの参照を管理しています。

Nugetは、内部dllを管理するための答えになる可能性があるようです。

これが私たちの構造のサンプルです：

  • Framework.dll
  • Business.dll
    • 参照：Framework.dll
  • Business.X.dll
    • 参照：Framework.dll
    • 参照：Business.dll
  • Application.X.dll
    • 参照：Framework.dll
    • 参照：Business.X.dll
    • 参照：Business.dll

NuGetでこれを実現するために、アセンブリごとにnuget仕様/パッケージを作成しました。各パッケージには、依存するパッケージが含まれます。

  • Framework.1.0.nupkg
  • Business.1.0.nupkg
    • 依存：フレームワーク
  • Business.X.1.0.nupkg
    • 依存するもの：フレームワーク、ビジネス
  • Application.X.1.0.nupkg
    • 依存するもの：Framework、Business、Business.X

1）Framework VSプロジェクトを作成してビルドし、Framework.1.0.nupkgにパッケージ化しました。2）Business VSプロジェクトを開き、Framework.1.0.nupkgをインストールしてFramework.dllへの参照を追加しました。3）次にビルドしました。 Business VSプロジェクトをBusiness.1.0.nupkgとしてパッケージ化しました。4）アセンブリごとにこのプロセスを繰り返しました（参考までに、NuGetterを使用してこれを自動化しました）

ローカル開発者マシンとビルドサーバーの違いを調整するのに問題があります。

これが私の理解です：

  1. NuGetのパッケージ復元機能があるため、最終的なアセンブリをTFSに保存する必要はありません。
  2. アセンブリを参照する代わりに、NuGetを使用して参照が追加されます。たとえば、Business VSプロジェクトでは、フレームワークアセンブリはNugetFramework.1.0パッケージから追加されます。

ただし、これにより、アセンブリ開発者が新しい機能を構築/テストすることが困難になります。BusinessおよびBusiness.Xアセンブリで作業している開発者は、参照を削除/再読み込みせずに、ローカルで（自分のマシンで）機能をテストする方法を教えてください。Business.Xは、ローカルで構築されたBusiness.dllではなく、パッケージ化されたBusinessを参照するため、これが必要です。

私の目標：

  1. ビルドサーバーを使用して、バージョン管理された共有アセンブリを作成します
  2. コンシューマーアプリケーションがこれらのアセンブリへの参照を追加できるようにする
  3. 共有アセンブリの開発者がサーバービルドを要求する前にローカルで簡単にコンパイル/テストできるようにする

Nugetは＃1と＃2でうまく機能すると思いますが、＃3を達成できないようです。これを行うためのより良い方法はありますか？

情報/ポインタをありがとう！

4

1 に答える 1