3

NuGetを使用して、いくつかのWebAPIプロジェクトで使用している共有ライブラリを管理していますが、共有プロジェクトのさまざまなビット間の依存関係を管理する方法がわかりません。

私の共有ライブラリは、次の3つのプロジェクトを含むソリューションとして構成されています。

           +------MyUtils.Core------+
           |                        |
MyUtils.WebApi.Windsor    MyUtils.WebApi.Security

WindsorモジュールとSecurityモジュールはどちらもCoreに依存していますが、個別のNuGetパッケージとして展開できるようにする必要があります。

私の質問は、Coreをそれ自体でNuGetパッケージとして公開してから、そのパッケージをWindsorとSecurityに追加する必要があるのか​​、それともWindsorとSecurityプロジェクトの両方でCoreへのプロジェクト参照を追加してから別々のプロジェクトとして公開するのかということです。

後者の場合、WindsorとSecurityの両方を備えたプロジェクトを構築していて、そのうちの1つを別のバージョンのMyUtils.Coreを含むバージョンにアップグレードした場合、潜在的な競合のリスクがありますか？

4

1 に答える 1

1

質問を理解していると仮定して、私がすることは次のとおりです...

3パック作る。MyUtils.Core は依存関係がないため、最も簡単です。Core を作成すると、何らかの方法でバージョン番号が取得されます (アセンブリのバージョン番号を使用するか、手動で割り当てることができます)。

他の 2 つのパッケージを作成するときは、コア ( docs.nuget.org )の正確なバージョン番号を指定します。

例 MyUtils.WebApi.Windsor.nuspec:

<dependency id="MyUtils.Core" version="[1.0.1.1]" />

これを行うと、次のバージョン、たとえば 1.0.1.2 を使用するようにセキュリティを更新できます。ただし、両方を使用するプロジェクトでは競合を回避できます。バージョン番号が正確に指定されている場合、1.0.1.2 にも依存する Windsor のバージョンが見つからない限り、NuGet はセキュリティの更新を拒否します。互換性のあるパッケージが見つからない場合、更新はありません。可能であれば、セキュリティが更新されると両方が更新されます。

デフォルトでは、このようにバージョン番号が指定されていますが、

<dependency id="MyUtils.Core" version="1.0.1.1" />

この場合、MyUtils.Core >= 1.0.1.1 の任意のバージョンを意味します。したがって、デフォルトの構文を使用すると、Windsor と Security の両方を使用するプロジェクトで競合が発生する危険がありますが、正確なバージョンの構文を使用すれば競合を回避できるはずです。

別のルートに進み、Core 用のパッケージを作成せず、プロジェクト参照を使用したとしましょう。次に、必要な各パッケージに Core.dll のコピーを入れることになるでしょう。消費するプロジェクトは、一度に 1 つの Core.dll のコピーへの参照しか取得できません。NuGet をいじって、どの参照が追加されるかを確認する必要があります (最新バージョンと最近インストールされたもの)。そのため、プロジェクト参照を取得することは最善の解決策ではないようです。

もちろん、回避すべき衝突が実際にある場合にのみ、これを行う必要があります。1.0.1.2 に下位互換性がある場合、NuGet で既定の動作を許可しない理由はありません。

于 2012-06-16T15:54:26.550 に答える