従来、NuGetは接合された機能だ。コンパイラはNuGetパッケージのダウンロードはできるが、それを解釈しない。パッケージがダウンロードされた後、プロジェクトにインストールされる必要がある。これによって、アセンブリが参照が更新され、ファイルがコピーされ、カスタムのPowerShellスクリプトが走る。これは、壊れやすい動作で、開発者がパッケージの再インストールをする前に、マニュアルでプロジェクトファイルのクリーンにしなければならない場合もある。
新しいPackageReference機能では、ほとんどの問題が解消している。個別のアセンブリを参照するのではなく、パッケージそのものを参照できるからだ。
パッケージ参照は推移的でもある。つまり、あるパッケージを参照したら、それで完了ということだ。そのパッケージが必要とするパッケージを明示的に参照する必要はない。発表によれば、これによってパッケージのインストールと参照の性能は5倍になった。10分かかっていた処理が30ミリ秒になったという例もある。
また、ソリューションレベルのパッケージフォルダも削除された。依存物はユーザーのパッケージキャッシュからそのまま参照される。なぜ前からそうなっていないのか疑問を持つかもしれないが、以前のNuGetは“接合”された機能だということを考慮する必要がある。コンパイラがNuGetパッケージを理解しないため、プロジェクトファイル内で正しく設定されるには“ヒントパス”が必要だった。それぞれのユーザーがパッケージファイルを異なる場所に置くことができるので、これを使うのは選択肢にはならない。よって、ソリューションレベルのパッケージフォルダが作成され、相対のヒントパスを全ての開発者で同一にする、というふうになった。
バージョニング
NuGetプロジェクト参照のバージョニングサポートは大幅に改善された。ある使いたいパッケージのバージョンにレンジとワイルドカードが利用できる。レンジは次のような数学的構文が使われる。
- 最低でもバージョンx.y: [x.y
- バージョンx.yより大きい: (x.y
- バージョンx.yかそれ以前: x.y]
- バージョンx.yよりも前: x.y)
例えば、最低でもバージョン1.4.2で1.5は使わないのなら、“[1.4.2, 1.5)”と書く。バージョン1.4系なら “1.4.*”と書ける。
コンテンツはIncludeAssetsとExcludeAssetsタグで管理される。この二つはビルドプロセスでどのタイプのアセット(アナライザ、コンテントファイルなど)を同梱するかを変更するのに使う。タグをプライベートに設定することもできる。こうすると、開発では使うが次のライブラリには渡されない。
MSBuildでNuGetパッケージを作る
MSBuildでExecコマンドを実行して特定のファイルを渡すことでNuGetパッケージコマンドを起動できるが、CI環境でこの方法はうまくいかなかった。今回のリリースの一部として、MSBuildはプロジェクトをそのままパッケージできる。TargetFrameworksタグで複数のフレームワークを使う場合でも正常に動作する。
例えば、ターゲットのプラットフォーム別に異なるパッケージを参照する必要がある場合、PackageReferenceを使えば、MSBuildの標準の条件式でその参照を適用するかを表現できる。
後方互換性の問題
大きな問題は古いNuGetの機能をサポートしていないことだ。例えば、コンテントフォルダ、XDT変換、install.ps1/uninstall.ps1のパワーシェルスクリプトだ。
.NET Coreと.NET Standardのプロジェクトはこれらの機能が現時点では利用できる。VS 2017 Update 1 Previewをインストールすれば他のプロジェクトタイプでも利用できる。
Rate this Article
- Editor Review
- Chief Editor Action