2

NuGetを使用して、組織内で開発者フレームワークとツールを配布する方法を調査しています。サーバーをセットアップし、パッケージを生成して、消費するプロジェクトに追加することができます。私は今、これをより現実的な状況に拡大しようとしています。

私の場合、組織内のすべての開発チームに配布するフレームワークがあります。このフレームワークには、「コア」クラスライブラリと、Acme.Web、Acme.Silverlightなどのテクノロジ固有のライブラリのセットがあります。これらの各ライブラリは、「コア」アセンブリを参照します。

これらの各アセンブリを、他のパッケージ内の依存関係として設定される「コア」を含む独自のNuGetパッケージにパッケージ化しました。これは、開発者がクラスライブラリを作成するときに「コア」のみを参照することを選択する可能性があるだけでなく、Webアプリなどを作成するときにそれらのタイプも必要とするためです。

もう1つのアイデアは、他のすべてのパッケージの更新を必要とせずに、「コア」アセンブリの新しいバージョンをリリースできるということです。または私はできますか？

プロジェクトAがあり、NuGetパッケージCに依存するNuGetパッケージBを追加すると、パッケージCが更新されます。パッケージBを再構築、再パッケージ化、および再投稿せずに、この更新を配布することは可能ですか？もしそうなら、バージョン管理の問題がないことを確認するために私が取る必要があるステップはありますか？

4

1 に答える 1

7

次の依存関係グラフを考えると、あなたが尋ねている質問は次のように聞こえます。

->はに依存することを意味します

B 1.0 -> C 1.0

Cの更新がある場合、たとえばC 1.1の場合、その更新をCに公開し、Bを壊さずに消費者に更新してもらうことができるかどうかを知りたいと思います。

ここでアセンブリを梱包していると仮定します。その場合、あなたは間違いなくそれを行うことができます。NuGetは、厳密な名前を持つアセンブリでこれを機能させるためにいくつかのことを行います（つまり、必要なバインディングリダイレクトを追加します）。適切なバージョン管理を使用していることを確認する必要があります（この件に関するDavid Ebboの投稿を読むことを強くお勧めします）。

これがどのように機能するかについての基本的な理解を与えるため。あなたが3人のチーム、あなた、開発者1と2のチームにいるとしましょう。

  1. パッケージB1.0およびC1.0を会社のフィードに公開します
  2. 開発者1はB1.0をインストールし、C1.0を取得します
  3. Cに小さなバグ修正を加え、C 1.0.1と呼びます（壊れていないため）。Bを更新しません（つまり、C1.0.1ではなくC1.0に依存していることを意味します）。
  4. 開発者1はCを1.0.1に更新し、動作し続けます
  5. 開発者2はB1.0をインストールし、C 1.0.1（NuGetの依存関係解決の動作）を取得します。

上記のシナリオでは、バージョンをC1.0からC1.0.1に変更し、Bを再公開する必要はありませんでした。

ここで、大幅な変更を加えてバージョンをC 2.0に上げた場合は、Bを再パックしてバージョン番号を増やし、そのバージョンのBをC2.0に依存させることを検討してください。

B 2.0 -> C 2.0
于 2011-09-15T08:10:37.293 に答える