0

現在、VS ソリューションで TFS を使用して NuGet と統合する方法を調査しています。NuGet を使用する理由は、さまざまな TFS ブランチにまたがる共有ライブラリの問題を回避するためです。通常、共有ライブラリにリンクされたプロジェクト (相対 pat を使用) を持つソリューションがありますが、分岐はプロジェクト レベルであるため、このリンクは壊れます。

アイデアは、共有ライブラリを TFS に格納してから、内部の NuGet サーバーにデプロイすることです。

私が遭遇した問題の 1 つは、TFS 内に保存されている共有ライブラリを管理しながら、NuGet デバッグから引き出してコミットできることです。

例

Solution A
 - Core Library
 - Project A1
 - Project A2

開発者がソリューションを開いて、(アセンブリだけでなく) コア ライブラリ プロジェクトを NuGet にプルさせて、ソース コードにステップインして必要な変更を加えることができるようにしてほしいです。彼が Core Library にバグを発見した場合、私は開発者に次のことができるようにしてほしい:

  1. 変更を加える
  2. 再テストとデバッグ
  3. コードをチェックインします。

ステップ3がどのように機能するかわかりません。プロジェクトが NuGet 経由で取り込まれている場合、それは TFS バインド プロジェクトではありませんか? 開発者はどのように変更を行い、それをチェックインできるでしょうか? 彼は、TFS にバインドされている別のプロジェクトを開くことを余儀なくされ、それを確認してから NuGet に展開し、ソリューション A がコア ライブラリを再度取得することを確認します。

これを実現する方法と、NuGet、TFS、および共有ライブラリを使用する場合の推奨されるワークフローについて、私は少し漠然としています。

4

1 に答える 1

0

TFS を使用すると、TFS がすぐに使用できるソース インデックス作成をサポートしているため、少なくともソース ステップを機能させることができるはずです。Project Aこれには、ローカルでビルドする必要はなく、開発者がソースを用意する必要さえありませんProject A。VS は、デバッグ時にそれらを自動的にプルします (ソース サーバー サポートを有効にし、シンボルを正しく構成したと仮定します)。

ただし、変更を加えるには、開発者は適切に checkout する必要がありますProject A。変更をProject Aローカルでテストするために、開発者はProject Aビルド出力を NuGet のローカル パッケージ ソースとして使用して再ビルドするだけです。

このように、パッケージの復元をローカルで実行するだけですProject B(またはの消費者は誰でもProject A)。

于 2013-07-08T16:48:17.587 に答える