前回の投稿では、packages.configファイル方式とPackageReference方式の紹介と、packages.configファイル方式からPackageReference方式への移行方法を説明しました。
PackageReference方式では、packages.config方式で実現できていたことのいくつかができなくなっています。それらについて説明します。
パッケージインストール時のスクリプトが実行されない
packages.config方式では、パッケージをインストールしたときに、パッケージ内で定義されているインストール時の処理が実行されました。
しかし、PackageReference方式では、パッケージインストール時には、一部の処理が実行されません。
具体的にどういうことかというと、実在する以下のパッケージの例を挙げます。
パッケージを参照する側がpackages.config方式の場合
このパッケージでは、パッケージを参照する側がpackages.config方式の場合、パッケージインストール時に、プロジェクトフォルダーにApplicationInsights.configファイルを追加、または、自動編集(設定の追加)をします。パッケージのアンインストール時には追加した設定を削除しするための、自動編集が行われます。
パッケージを参照する側がPackageReference方式の場合
しかし、パッケージを参照する側がPackageReference方式の場合、パッケージインストール時に、プロジェクトフォルダーにApplicationInsights.configファイルが追加されたり、自動的に編集されたりしません。
このパッケージにおいては、ApplicationInsights.configは、AzureのApplicationInsightsを使うときの設定ファイルです。そのファイルのひな型をインストール時に作成してくれるので、非常に便利です。
PackageReference方式に移行すると、ApplicationInsights.configファイルを作成してくれません。
なぜこのようなことが起きるのでしょうか？
nugetパッケージを作成するときの仕様が変更になった
原因は、nugetパッケージを作成するときの仕様が変更になったことです。
同じnugetパッケージであっても、パッケージを参照する側がpackages.config方式の場合は、旧仕様で動作し、PackageReference方式の場合は、新仕様で動作します。
パッケージを参照する側からの視点での仕様変更については、以下に記載されています。
Migrate from packages.config to PackageReference(英語)
packages.config方式からPackageReference方式への移行時(マイグレード時)に影響する主な仕様変更は以下の通りです。
- パッケージがインストールされるとき、”install.ps1″ スクリプトが無視されます
- パッケージがインストールされるとき、”content” アセットは利用できません
- パッケージがインストールされるとき、XDTトランスフォームは適用されません
- パッケージがインストールされるとき、”lib”アセットのルートフォルダーにあるアセンブリは無視されます
これらがどういうことかというと、次に説明します。
nugetパッケージ仕様変更によるPackageReference方式での制限
パッケージがインストールされるとき、”install.ps1″ スクリプトが無視されます
nugetパッケージには、install.ps1およびuninstall.ps1という名前で、PowerShellスクリプトを用意しておくと、パッケージインストール時にinstall.ps1が実行され、アンインストール時にuninstall.ps1を実行されました。これにより、パッケージの利用に必要なカスタムな処理をすることができました。
PackageReference方式では、これらのスクリプトファイルがあっても、PownerShellスクリプトは実行されなくなりました。
パッケージがインストールされるとき、”content” アセットは利用できません
nugetパッケージは、内部に”content”アセット(contentフォルダー)を持つことができました。パッケージ内にcontentフォルダーが存在すると、それらのファイルをパッケージを参照したプロジェクト側にコピーされます。
PackageReference方式では、”content”アセットは無視されます。代替えとして、”contentFiles”アセットが用意されました。PackageReference方式においても、プロジェクトにファイルをコピーしたい場合は、パッケージ側を新仕様にも対応する必要があります。
パッケージがインストールされるとき、XDTトランスフォームは適用されません
これは、contentアセットにxxxxx.install.xdt / xxxxx.uninstall.xdtというファイル(xxxxxは任意のファイル名)を用意しておくと、パッケージのインストール時、および、アンインストール時に、xxxxxというXML形式ファイルに対して、XMLファイル内の変換(タグの追加や削除など)をタグ単位などで行うことができます。なお、XDTは、XML Document Transform(XML文書変換)の略です。
PackageReference方式では、インストール時・アンインストール時に、このXDT変換が実行されません。もし、XDT変換を実行させたい場合は、ビルド時に行うスクリプトを用意するなどの処理が必要となります。ビルド時にXDT変換を行う手法は、機会があれば紹介したいと思います。
パッケージがインストールされるとき、”lib”アセットのルートフォルダーにあるアセンブリは無視されます
旧仕様(packages.config方式)では、nugetパッケージ内のlibアセット直下にあったアセンブリファイルも利用されていました。
新仕様(PackageReference方式)では、libアセットの直下にあるアセンブリファイルは利用されなくなりました。新仕様では、必ずTFM(Target Framework moniker)形式の名前のサブフォルダーにアセンブリファイルを配置する必要があります。TFM形式の名前とは、”net46″, “netstandard2.0”, “netcoreapp3.1″とかの名前となります。
まとめ
PackageReference方式向けの仕様変更により、上記に挙げた制限が発生します。nugetパッケージが旧仕様(packages.config方式)と新仕様(PackageReference方式)に両対応できていれば特に問題ありません。使用しているnugetパッケージが両対応できていない場合は、上記のような制限が発生し、最適な状態にならない可能性があるというのを気に留めておく必要があります。
先に挙げた、Microsoft.ApplicationInsights.WindowsServer.TelemetryChannel 2.14.0パッケージでは、libアセットは両対応できているので、アセンブリファイル自体は正しく利用できます。しかしながら、contentアセットは新仕様に対応できていません。そのため、ApplicationInsights.configファイルがコピーされることもなく、また、既存のApplicationInsights.configファイルをXDT変換を使用して更新してくれることもありません。
以上、packages.config方式をPackageReference方式に移行したときの制限に関する投稿でした。