MS_NuGet - NetDevInfraWGinOSSConsortium/NetDevInfraWiki GitHub Wiki

NuGet

概要

背景

  • 昨今の技術の複雑化により、GAC では 1 台の PC に複数の環境を構築・共存させることが
    難しくなってきた。

  • そこで、NuGet では、パッケージ管理システムにより、

    • Web からダウンロードしたパッケージをローカルの packages フォルダに格納するようにした。
    • これにより、１台の PC に複数の環境を共存させることが、以前と比べて容易になった。

  • Visual Studio のバージョン

    • Visual Studio 2010 以前に NuGet を使用する場合は、
      個別に Visual Studio に追加インストールする必要があった。
    • Visual Studio 2012 以降では、NuGet も Visual Studio に同梱されるようになった。

補足（GAC からの脱却という文脈）: この「背景」は、
.NET Framework のマシン共有型の配置からの
転換を述べたものである。

【GAC】       マシンに 1 つ。全アプリが共有
               → 「A は v1、B は v2 が必要」で詰む

【NuGet】     アプリごとに packages フォルダへ
               → アプリ単位でバージョンを選べる

この発想は .NET Core 以降さらに徹底され、
GAC そのものが廃止された。
.NETバージョンアップ の
「同居の可否」の議論と一続きの話である。

サイト

  • 以下の２つのサイトがある。

    • nuget.org

      • NuGet を使用してインストールできるパッケージ (NuGet パッケージ) が多数公開されている。
      • 自作ライブラリのパッケージ (NuGet パッケージ) を作成して、公開することもできる。

    • symbolsource.org

  • サイトの概要

補足（最新化）: シンボルの公開先は現在
nuget.org 自身のシンボル サーバーが標準である
（.snupkg 形式のシンボル パッケージを nuget.org に push する）。
symbolsource.org を使う必要は無くなった。

さらに Source Link を使えば、
シンボル パッケージすら不要で GitHub 等のソースへ直接たどれる
（PDB にソースの URL を埋め込む方式）。
詳細は
ビルド環境と開発環境のソースファイルパスを一致させる（PDB）。 を参照。

詳細

NuGet を使うメリット

一連のパッケージ管理が簡便になる。

  • 古いパッケージの参照設定を解除
  • 古いパッケージを削除
  • 新しいパッケージに更新
  • 新しいパッケージを参照設定に追加

パッケージの依存関係の定義と維持

パッケージの依存関係を定義でき、既定では依存関係が壊れるような
パッケージの更新・削除はできず、パッケージ間の関連をキレイに保つことができる。

NuGet で配布・インストールできる、主なパッケージの種類

.NET アセンブリ (*.dll)

ASP.NET MVC や、Entity Framework など

JavaScript や、CSS などのライブラリ

jQuery や、jQuery の各種プラグインなど

補足（最新化）: JavaScript / CSS を NuGet で配るのは現在は非推奨である。
フロントエンドの資産は npm（および libman）で管理するのが標準になった。

【かつて】NuGet で jQuery を入れる → Scripts フォルダに展開される
【現在】  npm / LibMan / CDN で取得する

ASP.NET Core 以降、
フロントエンドとバックエンドのパッケージ管理は
明確に分離されている。

NuGet で使用するファイル／フォルダ

各プロジェクトに含まれる packages.config

  • 当該プロジェクトにインストールされている NuGet パッケージが記述される
  • Visual Studio 2017 以降は、Project ファイルに統合された PackageReference を使用できる
    （NuGet を使用したパッケージ管理）。

ソリューションフォルダ直下の packages フォルダ

  • プロジェクトにインストールした NuGet パッケージ本体が格納される
  • Visual Studio 2017 以降は、PackageReference を使用すると、
    packages フォルダは生成されなくなる
    （NuGet を使用したパッケージ管理）。

補足（PackageReference が既定になった意味）: この 2 つの方式の違いは、
移行やトラブルシュートで頻繁に効いてくる。

packages.config（旧） PackageReference（現在の既定）
記述場所 専用の XML ファイル .csproj の中
依存関係 すべてを平坦に列挙（推移的依存も書かれる） 直接依存だけ書く（推移的依存は自動解決）
実体の置き場 ソリューション配下の packages\ グローバル パッケージ フォルダ（~\.nuget\packages）
リポジトリの汚れ packages フォルダが混入しやすい 混入しない
復元 nuget restore dotnet restore（ビルド時に暗黙実行）

特に**「直接依存だけ書けばよい」**のが大きく、
パッケージ更新時に推移的依存を手で追う必要が無くなった。

なお、.NET Core 系のプロジェクトは PackageReference のみであり、
packages.config は .NET Framework 時代の
旧形式プロジェクトに限られる。
.NET Coreへの移行 では、
この変換が最初の作業になる。

トラブルシュート

NuGet 使用時

補足（これらのエラーの共通の原因）: 一覧のエラーは、
大半が同じ根を持つ。

「同じアセンブリの、違うバージョンが要求されている」
      │
      ├ ビルド時に検出   → MSB3247（バインディング競合）
      ├ 復元時に検出     → NU1605（ダウングレード）、NU1701（TFM 不一致）
      └ 実行時に発覚     → FileLoadException

.NET Framework では
bindingRedirect（app.config / web.config）で
「どのバージョンに寄せるか」を明示して解決していた。
.NET Core 系では自動的に最も高いバージョンに寄るため、
この種のエラーは大幅に減っている。

NU1605（ダウングレード）は、
推移的依存が要求する版より低い版を直接参照しているときに出る。
直接参照の版を上げるのが正しい対処。

ビルド時（MSBuild）

参考

Open棟梁 Wiki

移行メモ（リンク切れ）: 原文はここから Open棟梁 Wiki の\n> 「NuGet対応」ページを参照していたが、元 Wiki 側に実体が存在しない\n> （ダンプにも該当ページが無い）ため、リンクを外した。

マイクロソフト系技術情報 Wiki

Microsoft Learn

Tags: 移行, .NET開発, デプロイ, NuGet

このWikiは「Open棟梁Project」,「OSSコンソーシアム 開発基盤部会」によって運営されています。

⚠️ **GitHub.com Fallback** ⚠️