web-dev-qa-db-ja.com

痛みのないローカル開発とNuGetパッケージの参照

ローカル開発の問題を回避しながら、クラスライブラリのバージョン付きNuGetパッケージを公開して利用しようとしています。 Visual Studioソリューションのレイアウトのサンプルを次に示します。

| Libraries
  | LibraryA
  | LibraryB
  | LibraryC
| Applications
  | ApplicationD
  | ApplicationE

これは、共有クラスライブラリと複数のアプリケーションの両方を含む単一のソリューションです。現在、アプリケーションによるクラスライブラリへの参照は、ローカルのソリューション内参照です。

ライブラリ（A、B、C）をバージョン付きのNuGetパッケージとして公開し、必要に応じてアプリケーション（D、E）で参照されるようにします。これにより、共有ライブラリへの変更を、デプロイされているアプリケーションの更新から独立させることができます。これがなければ、1つのライブラリを変更すると、バイナリが12以上のアプリケーションで変更される可能性があり、そのすべてを技術的にテストする必要があります。これは望ましくないことであり、NuGetを使用したバージョン管理によってこれが修正されます。

ただし、LibraryAとApplicationDのコンテンツを同時に更新したいとします。 NuGetに切り替えた後でこれを行うには、LibraryAに変更を加えてコミットし、パッケージが作成されるのを待って、ApplicationDにLibraryAへの参照を更新するように通知し、ApplicationDでテストまたは開発する必要があります。これは、ローカルのソリューション内参照を使用して両方を同時に処理するよりもはるかに複雑です。

複数のプロジェクトやアプリケーションにまたがる場合でも開発をシンプルに保ちながら、共有クラスライブラリのバージョン管理されたNuGetパッケージの堅牢性を確保するためのより良い方法は何ですか？私が見つけた他の唯一の解決策はすべて、NuGetパッケージとローカルプロジェクトの間でApplicationDの参照を常に変更しなければならないなど、オーバーヘッドや頭痛が多すぎることです。

編集：前提を明確にするために、この質問は次のことを前提としています。

  • アーキテクチャ（ソリューションとプロジェクトの編成）を大幅に再編成することはできません
  • 共有ライブラリは重要な頻度で変更されます
  • 共有ライブラリを変更しても、アプリケーションを強制的に更新することはできません
  • アプリケーションは異なるバージョンの共有ライブラリを参照できます
c#visual-studiovisual-studio-2013nugetnuget-package
44
jmsb

残念ながら、実際には両方の長所を活かす方法はありません。私の会社では、常にNuGetパッケージを参照することによるほとんどの負担を軽減する、高速なビルド/デプロイプロセスを使用してそれをある程度軽減しました。基本的に、すべてのアプリケーションは、ローカルのNuGetリポジトリでホストされている同じライブラリの異なるバージョンを使用します。独自のソフトウェアを使用してパッケージを構築、展開、およびホストするため、ライブラリを更新してから、別のソリューションでそのNuGetパッケージを更新するのが非常に迅速になります。基本的に、見つかった最速のワークフローは次のとおりです。

  1. ライブラリに変更を加える
  2. 1ずつインクリメントされたバージョンのライブラリを自動的にビルドして内部NuGetフィードにデプロイします
  3. コンシューマーアプリケーションのNuGetパッケージを更新する

チェックインから消費プロジェクトの更新までの全体のプロセスには、約3分かかります。 NuGetリポジトリには、デバッグに非常に役立つシンボル/ソースサーバーもあります。

2
John Rasch

多少の作業は必要ですが、適切な参照にCondition属性を追加することで、条件付き参照を設定するために.csprojファイルを手動で編集することが可能です。

[〜＃〜] edit [〜＃〜]これらの条件をItemGroupsに移動しました。これは、これが私の言及した本番コードがどのように機能しているかのようで、これが可能であるという言及がありましたVS 2013の問題。

<ItemGroup Condition="'$(Configuration)' == 'Debug Local'">
    <!-- Library A reference as generated by VS for an in-solution reference, children unmodified -->
    <ProjectReference>...
</ItemGroup>

<ItemGroup Condition="'$(Configuration)' == 'Debug NuGet'">
    <!-- Library A reference as generated by NuGet, child nodes unmodified --> 
    <Reference Include="LibraryA">...
</ItemGroup>

これにより、プロジェクトDおよびEで、ライブラリを異なる方法で参照する "Debug NuGet"と "Debug Local"の構成が可能になります。その後、構成がプロジェクト内の適切な構成にマップされている複数のソリューションファイルがある場合、エンドユーザーにはほとんどの操作で「デバッグ」と「リリース」しか表示されません。これらはソリューション構成であるため、 A、B、Cプロジェクトを編集するための完全なソリューションを開く必要があります。

ここで、A、B、Cプロジェクトを邪魔にならないようにするために、サブリポジトリとしてマークされたフォルダーの下に設定できます（Gitなど、これをサポートするSCMを使用している場合）。ほとんどのユーザーはABCプロジェクトにアクセスしていないため、サブリポジトリをプルする必要はなく、代わりにNuGetから取得しています。

メンテナンスに関しては、VSが条件付き参照を編集せず、コンパイル時にそれらを尊重することを保証できます-VS 2010と2013の両方を実行しました（[〜＃〜] edit [〜＃〜] ：プロフェッショナルバージョン。ただし、Expressで同じことを行うことを徹底的に検討しましたが、同じ条件付き参照プロジェクトを使用しています。 VSよりも注意してください。参照はバージョンにとらわれず、NuGetがバージョンを維持する必要がある唯一の場所になり、他のNuGetパッケージと同様に行うことができます。私は期待していますが、NuGetが条件付きリファレンスと戦うかどうかはテストしていません。

[〜＃〜] edit [〜＃〜]条件付き参照はDLLの欠落に関する警告を引き起こす可能性がありますが、実際にはコンパイルや実行を妨げないことに注意することもできます。

[〜＃〜] edit [〜＃〜]これをまだ読んでいる人のために、私は今（7/2019）IDEがこれらの変更に友好的であり、それまたはパッケージマネージャーがそれらをオーバーライドする場合があります。注意して続行し、常にコミットを読んでください！

24
David

私はこれが2年前の投稿であることを知っていますが、同じ状況に直面しているときに見つけました。 VS2015でもこれが見つかりました。現在テスト中です。私は戻ってきて、それに応じて私の答えを調整します。

https://marketplace.visualstudio.com/items?itemName=RicoSuter.NuGetReferenceSwitcherforVisualStudio2015

9
JayR

.NET Core（2.x ++）のアップデート

.NET Core 2.xには、この機能が組み込まれています。

プロジェクトBのプロジェクトAへのプロジェクト参照があり、プロジェクトAが適切なパッケージ情報（Properties -> PackageとPackage idがNuGetパッケージIDに設定されている）を持つ.NET標準またはコアプロジェクトである場合、プロジェクトBの.csprojファイルに通常のプロジェクト参照を含めることができます。

<ItemGroup>
  <ProjectReference Include="..\..\A\ProjectA.csproj" />
</ItemGroup>

（dotnet pack）プロジェクトBをパックすると、プロジェクトAのPackage idが原因で、生成された.nuspecファイルは、他のNuGetとともに、そのパッケージIDへのNuGet依存関係でセットアップされますビルドされたDLLファイルを含めるだけでなく、.

<dependencies>
  <group targetFramework=".NETStandard2.0">
    <dependency id="Project.A" version="1.2.3" exclude="Build,Analyzers" />
    <dependency id="Newtonsoft.Json" version="12.0.2" exclude="Build,Analyzers" />
  </group>
</dependencies>
4
GTHvidsten

ApplicationDのプロパティで、「参照パス」タブに移動し、LibraryAの出力フォルダーのパスを追加します。次に、LibraryAを変更してビルドすると、ApplicationDの次のビルドでは、変更されたLibraryAが使用されます。

完了したら、「参照パス」を削除し、参照されているNuGetパッケージバージョンを更新することを忘れないでください。

1
hectorct