.NET Frameworkから .NET Coreへ（2）
3．.NET API アナライザーを使用して、.NET Coreで利用できないAPIを検出して、APIが利用できるかどうかを評価する。
.NET API アナライザーは、コード上に含まれる互換性リスクや非推奨APIの検出などを行うRoslynベースのコード分析アナライザーです。NuGetパッケージで公開されており、Visual Studioでプロジェクトに追加すると自動的にコードの監視が行われます。
前述した.NET Portability Analyzerと異なり、移行の分析目的だけではなく、以下のようなAPIの検出を行います。
- .NET Standardで利用することができない NET Framework 4.6.1移行のAPI
- .NET Standardで実行するとPlatformNotSupportExceptionをスローしてしまうAPI
- Windows以外のクロスプラットフォームの実行時に問題が発生する可能性のあるAPI
- 現在は非推奨となっているAPI
実行するためにはNuGetパッケージMicrosoft.DotNet.Analyzers.Compatibilityをプロジェクトに追加します。
パッケージマネージャーコンソールから行う場合、以下を実行します。
Install-Package Microsoft.DotNet.Analyzers.Compatibility -Version 0.2.12-alpha
追加するとコードエディターの問題の箇所にライトが表示されて警告内容を確認できます。
また、警告の一覧は［エラー一覧］ウインドウの中にも表示されます。
以下のリンクも参考にしてください。
4．Windows互換機能パックの利用を検討する。
.NET Portability Analyzerや.NET API アナライザーで検出された.NET Core未対応の機能のうち、.NET Framework（つまり、Windows）のみ存在するテクノロジーについては、Windows互換機能パックを利用できる場合があります。
Windows互換機能パックは.NET Standard 2.0の拡張機能であり、.NET Frameworkにのみ存在していた多くのWindows依存機能を利用できるようにするためのパッケージです。NuGetパッケージMicrosoft.Windows.Compatibilityとして提供されています。
ただし、このパッケージを使用する箇所についてはWindows上でしか利用できません。そのため、クロスプラットフォームで実行するモジュールを作成する場合、これらの機能が利用できないよう判定を行う必要があります。判定は以下のコードで行うことができます。
if (RuntimeInformation.IsOSPlatform(OSPlatform.Windows))
{
// Windows上でのみ実行するコード
}
Windows互換機能パックを使用することで利用可能となる機能については、以下のページで確認できます。
5．Visual Studioの機能を利用して依存関係の記述をpackage.configからPackageReferenceへ変換する。
NuGetパッケージへの依存がある場合、package.configからPackageReferenceへ変換する必要があります。
従来、.NET Frameworkでは依存関係のあるパッケージをpackage.configで管理していましたが、.NET Coreでは依存関係のあるライブラリは、すべてプロジェクトファイル内で直接管理するようになりました。
Visual Studio 2017 Version 15.7以降には、package.config形式からPackageReference形式へのプロジェクト移行を行う機能が追加されました。
この機能を使用することでソリューション内のpackagesフォルダーで管理されていたパッケージがグローバルパッケージフォルダーで管理するように変更されます。
また、package.configに対する新機能の開発は今後継続されないと表明されています。
package.configからPackageReferenceへの移行は、プロジェクトエクスプローラーから［package.config］を右クリックしてコンテキストメニューから［package.configをPackageReferenceに移行する］を選択します。（※1）
※1：現在、既知の問題として［package.configをPackageReferenceに移行する］のメニューを表示しない場合があるとMicrosoftのdocsに記載されています。docsに回避策が記されているので、表示されない場合はお試しください。
package.configの解析によって、［最上位レベルの依存関係］と［遷移的な依存関係］に分類されます。
［最上位レベルの依存関係］は、プロジェクトに直接インストールしたNuGetパッケージを示しています。［遷移的な依存関係］は、プロジェクトに直接インストールしたパッケージの依存関係として導入されたNuGetパッケージと判定されたパッケージです。
［遷移的な依存関係］と判定されたパッケージは［最上位］にチェックを行うことで［最上位レベルの依存関係］として扱うことができるようになります。
以上で問題なければ、［OK］ボタンをクリックすることで移行が行われます。移行の結果、問題があるようであれば、ロールバックすることもできます。
ロールバックする場合の手順は以下の通りです。
- 移行されたプロジェクトを閉じます。
-
package.configのバックアップ（通常は
<solution_root>\MigrationBackup\<unique_guid>\<project_name>\に作成される）からプロジェクトフォルダーにコピーします。 - プロジェクトを開きます。
- メインメニューから［ツール］＞［NuGetパッケージマネージャー］＞［パッケージマネージャーコンソール］を開き、以下のコマンドを実行します。
update-package -reinstall
移行が正常に行われたら、NuGet.Build.Tasks.Packパッケージの追加を行います。
6．プロジェクトファイルの変換を行う
.NET Coreで使用するプロジェクトファイルは、.NET Frameworkと同様の「*.csproj」という拡張子のテキストファイルです。
このファイルはプロジェクト内の構成ファイルや依存関係、ビルド方法などを記述し、MSBuildを使用してビルドされます。しかし、以前のプロジェクトファイルは、記述形式すべき項目が多く、可読性も低いことから、現在の.NET Coreで使用されるプロジェクトファイルでは、より軽量な記述が行えるよう改良が加えられました。
例えば、この後作成するサンプルアプリのプロジェクトファイルは以下のように記述されています。
<Project Sdk="Microsoft.NET.Sdk.WindowsDesktop">
<PropertyGroup>
<OutputType>WinExe</OutputType>
<TargetFramework>netcoreapp3.1</TargetFramework>
<UseWPF>true</UseWPF>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="C1.Win.C1TileControl.Ja" Version="4.5.20193.393" />
</ItemGroup>
</Project>
見ての通り、構成ファイルやビルドオプションなどの細かな記述はなく、アプリをビルドするために必要最低限の情報を記述することで、アプリの種類に合わせた参照やビルドオプションなどの初期設定は既定値のものがそのまま適用されます。それ以外にも、以前よりも簡素な記述ができるように、さまざまな機能追加が行われており、以前の形式から進化しています。
すでに新しいプロジェクトファイルで作成されている場合は、TargetFrameworkを.NET Coreで利用できるFrameworkに変更するだけで問題ありません。ですがプロジェクトファイルが以前の形式である場合、プロジェクトファイルの移行を行う必要があります。
プロジェクトファイルの移行は、.NET Coreの新しいプロジェクトを作成してソースコードを移行するか、ツールを利用してプロジェクトファイルの変換を試みます。
小規模なソリューションや小さなプロジェクトであれば、dotnet try-convertという変換ツールを利用できる場合があります。このツールはプロジェクトファイルの形式を新形式に変換を試みてくれます。ただし、必ずしも正しく変換できることを保証するものではありません。また、ツールを利用したことで動作に変化が発生する可能性もあるため、あくまで補助的なツールとして利用します。
いずれの場合でも、できあがったプロジェクトに対して、しっかりとしたテストを行うことが必要です。
.NET Coreで使用できない.NET Frameworkテクノロジー
.NET Coreでマルチプラットフォーム対応になったことで、Windows独自の機能をサポートするためのライブラリが公開されました。
このライブラリを利用することで.NET Core環境でも多くの機能が継続して利用できるようになりますが、Frameworkの最適化や最新化を行う中で加えられた破壊的変更も存在します。
代表的なものとして以下が挙げられます。
- AppDomain
- .NET Remoting
- Code Access Security（CAS）
- 透過的セキュリティコード
- System.EnterpriseServices
他にも、どのような破壊的変更が存在するのかを確認するページが用意されています。ターゲットバージョンと移行バージョンを選択すると、バージョン間で行われた破壊的変更を確認できます。
- 参考リンク：破壊的変更のセレクター
