.NET Framework→.NET 6モダナイズの初めの一歩「移行計画（手間やコストの見積もり）」の作成に便利なツール：.NET 6移行入門（3）

.NET 6の現状を把握し、具体的な移行方法を学ぶ連載。今回は、「移行計画（手間やコストの見積もり）」の作成に便利なツールについて。

[鈴木友宏，NTTデータ先端技術株式会社]

　「.NET 6」は.NET Frameworkが.NETに統合されて初めてのLTS（Long Term Support）リリースです。連載第1回でも述べた通り、今後も.NET Frameworkのサポートは続きますが、あくまでも「既存環境の維持」のためのサポートであり、今後積極的な機能追加がされることはありません。

　セキュリティパッチも継続的に提供されますが、.NETランタイムのセキュリティ脆弱（ぜいじゃく）性の緩和策ロードマップにある「Hardware-enforced Stack Protection」（ハードウェア強制型スタック保護）や「W^X」（write xor execute：書き込みと実行の排他）のように、.NETランタイムの構造に手を入れるような対策は.NET 6以降にのみ実装されます。基本的に.NET Frameworkでは提供されません。

　このような状況から考えて今は.NET 6への移行を進めるには絶好のタイミングであり、.NET Frameworkアプリの.NET 6への移行を検討している方々も多いことでしょう。

　.NET 6の現状を把握し、具体的な移行方法を学ぶ本連載「.NET 6移行入門」。今回は「移行計画（手間やコストの見積もり）」の作成に便利なツールについて解説します。

移行における最大の障壁

　.NETに限らず、アプリを最新の環境に移行を実施する場合の最大の障壁は「移行に要する予算の確保」です。新規アプリ開発には予算が付きやすいものですが、既存アプリの移行に対して高額な予算の承認を得るのは困難です。

　SIer、自社開発などにかかわらず移行を実施するには、移行に関する【1】作業内容、【2】リスク、【3】実施計画、【4】コストをまとめた「移行計画」をステークホルダーに分かりやすく説明し、理解と承認を得ることが必要です。

　しかし、移行先の環境の知見が少ない段階で、これら【1】〜【4】を網羅した精度の高い移行計画を作成するのは非常に困難です。すなわち、ステークホルダーの理解を得るのも困難となるという問題に悩まされます。

ツールを使用して移行に必要な作業量を見積もる

　.NET Frameworkから.NET 6への移行は全て手作業で実施する必要はなく、一部作業を自動化できるツールも存在します。つまり、移行時に大きな負担になるのは「ツールで移行できず必ず手作業が必要になる移行作業」です。

　よってこの「必ず手作業が必要になる移行作業」がどのくらいの作業量があるかが分かれば、コストも見積もることができ、精度の高い移行計画を立案できます。

　この問題を解決するのに適したツールが、「.NET Portability Analyzer」と「.NETアップグレードアシスタント」です。本来、この2つのツールは移行時に使うツールですが、使い方の視点を変えることによって、移行計画の作成に効果的に利用できます。

　.NET Portability Analyzerは、移行先の環境（今回は.NET 6）で使用できない（ビルドが通らず代替が必要な）APIを特定するツールです。

　.NETアップグレードアシスタントは、.csprojファイルの書式変更やsyntax、名前空間の問題でビルドが通らないコードを、移行先の環境（今回なら.NET 6）の新しい構文に変換するツールです。

　一般的な移行作業の手順と、その中で.NET Portability Analyzerと.NETアップグレードアシスタントで自動化可能な作業との関係は次の通りです。

1. ソリューション内で.NET 6対応に書き換える必要がある箇所をリストアップ
   1. .csファイルのアプリコードにおいて移行先でAPIが非サポートのため書き換えが必要な箇所のリストアップ（※1）
      →.NET Portability Analyzerで自動化可能
   2. .csprojファイルの書式や構文が変更されるために書き換えが必要な箇所のリストアップ
      →2.の工程で、.NETアップグレードアシスタントで自動変換できるので、この段階でリストアップする必要はない
2. .csprojの書き換え、*.csファイルのアプリコードの書き換え
   1. 自動で書き換え可能な箇所
      →.NETアップグレードアシスタントで自動化可能
   2. 手動でのみ書き換え可能な箇所（※2）
3. 全機能のテスト

　上記の手順とツールによるサポートを考慮すると、「必ず手作業が必要になる移行作業」の作業量を見積もるには、ツールで試験的に移行作業を行い、下記（※1）（※2）について具体的にどのような作業が必要かを精査すればよいことになります。

• （※1）.csファイルのアプリコードにおいて移行先でAPIが非サポートのため書き換えが必要な箇所
• （※2）手動でのみ書き換え可能な箇所

　もちろん、全ての移行作業が見積もれるわけではありませんが、このようにツールを利用することによって、移行作業を見積もる負荷は大きく下げることができます。ドキュメントベースの調査より精度の高い移行計画を作成することもできます。

ツールの利用方法

　.NET Frameworkアプリの.NET 6への移行で特に負担が大きいのは、歴史が古く開発時のドキュメントが残っていない塩漬けの資産が多いWindowsフォームとASP.NET Webフォームです。このうち、ASP.NET Webフォームは残念ながら.NET 6ではサポートされておらず移行できませんが、実はWindowsフォームはかなり手厚くサポートされており、.NET 6に移行しても十分に利用可能です。

　ここからは、Windowsフォームアプリを例に.NET Portability Analyzerと.NETアップグレードアシスタントを利用して「必ず手作業が必要になる移行作業」の作業量を見積もる方法を紹介します。

.NET Portability Analyzer

　.NET Portability Analyzerは移行先のプラットフォーム（今回なら.NET 6）で使用できない（ビルドが通らず代替が必要な）APIを特定できるVisual Studio拡張機能です。

　サポートされていなく手動で代替が必要な箇所を探すときに、ドキュメントを読んでサポートされていないAPIを手動でリストアップしたり、ソースコードを自分で解析したりといった作業が不要になります。メニューからツールを実行するだけで、数分程度でレポートを作成してくれるので、移行を実施したときに発生すると想定される作業の量を簡単に見積もることができます。

　.NET Portability Analyzerの詳細については下記リンクを参照してください。

• https://docs.microsoft.com/ja-jp/dotnet/standard/analyzers/portability-analyzer

　.NET Portability Analyzerは下記リンクからダウンロードできます。

• https://marketplace.visualstudio.com/items?itemName=ConnieYau.NETPortabilityAnalyzer

注意

　2022年3月1日現在、移行先のプラットフォームとして.NET 5までしか対応していません（.NET Frameworkからの移行という観点では移行先を.NET 5に設定して利用しても実害はほとんどありません）。

.NET Portability Analyzerの使い方

　Visual Studioの「ツール」→「オプション」で設定画面が表示されます。移行先のプラットフォームを、今回なら.NET 6がまだないので「.NET 5」でチェックします。

　プロジェクトの右クリックメニューから、「Analyze Project Portability」を実行します。

　分析が始まります。

　レポートが作成されるので開いてみましょう。

　移植性のサマリーの値が「98.45％」になっているので、移植できないAPIが含まれていることが分かります。

　「サポートされていないAPIは何か」は、「Details」のシートを確認すると分かります。

　「DataGrid」とそのメンバーが「Not supported」です。よって、このアプリではDataGridを.NET 6で利用できるAPIに変更しなければいけないことが分かります。

　このような手順で、サポートされていないAPIをリストアップできます。リストアップできたら、そのAPIについて調査します。

　例えばDataGridについて「docs.microsoft.com」で「DataGridクラスリファレンス」を確認すると「代わりに DataGridViewコントロールを使用してください。」と記載されているので、「DataGrid」を「DataGridView」に置き換えればよいことになります。

.NETアップグレードアシスタント

　.NETアップグレードアシスタントは.NET Frameworkのソリューションを移行先（今回であれば.NET 6）に移行する際に定型的に必要になる変更を自動化し、手作業が必要な箇所を支援してくれます。

　.NETアップグレードアシスタントの詳細については下記リンクを参照してください。

• https://docs.microsoft.com/ja-jp/dotnet/core/porting/upgrade-assistant-overview

　例えば、Windowsフォームアプリの場合、自動変更される内容は次の通りです。

• .NET Frameworkの.csprojファイル（非SDK形式）を.NET 6（SDK形式）に変換
• app.configファイルのpackages.configファイルの内容を必要に応じて変更
• .NET Frameworkから.NET 6への移行で必要になる定型的なコード変換
• Windows 互換機能パック「Microsoft.Windows.Compatibility」パッケージの追加
• アナライザー「Microsoft.DotNet.UpgradeAssistant.Extensions.Default.Analyzers」パッケージの追加

Windows互換機能パックとは

　Windows互換機能パックは、.NET Frameworkのみに存在するAPIおよびテクノロジーを.NETでも利用できるようにするパッケージです。簡単にいえば、.NET FrameworkのWindows依存のAPIを.NETにより再実装したものです。

　.NET Frameworkのコードを.NET 6に移行してWindows上で動かす場合、Windows互換機能パックによって既存のコードがほとんどそのままで動作します。

　Windows互換機能パックの詳細については下記リンクを参照してください。

• https://docs.microsoft.com/ja-jp/dotnet/core/porting/windows-compat-pack

アナライザー「Microsoft.DotNet.UpgradeAssistant.Extensions.Default.Analyzers」パッケージとは

　アナライザー「Microsoft.DotNet.UpgradeAssistant.Extensions.Default.Analyzers」パッケージを追加すると、移行で問題が検出されたソースコードにVisual Studio上で警告が表示されるようになり、その後の手作業を支援してくれます。

　ツールで実施できる移行作業は簡単に試せるので、「ツールでカバーできる移行がどこまでであるか」「ツールでの変換後に必要な手作業のボリュームがどのくらいあるか」を容易に確認できます。

　変換の所要時間はソリューションに規模に応じて数分から数十分程度なので、変換後に必要となる作業の量の見当を簡単に付けることができます。

.NETアップグレードアシスタントの使い方

　.NETアップグレードアシスタントは.NET CLIツールです。PowerShellのようなコマンドシェル上で利用します。

　インストール、アンインストールの方法は次の通りです。

dotnet tool install -g upgrade-assistant

インストール

dotnet tool uninstall -g upgrade-assistant

アンインストール

　「-g」パラメーターを指定すると、PATH環境変数に自動的に追加される既定の場所（%USERPROFILE%\.dotnet\tools）にツールがインストールされます。

　インストール手順に関する詳細は、下記リンクを参照してください。

• https://docs.microsoft.com/ja-jp/dotnet/core/porting/upgrade-assistant-overview#installation-steps

ツールのアップデート

　ツールをしばらく使用してなかった場合は、アップデートをしておきます。

dotnet tool update -g upgrade-assistant

アプリのアップグレードの方法

　アップグレードを行うには、PowerShell のようなコマンド シェルを開き、アップグレードを行いたいソリューションやプロジェクトが配置されているフォルダに移動します。

　アップグレードを行いたいソリューションやプロジェクトを指定して、 以下のコマンドを実行します。

upgrade-assistant upgrade .\WinFormsAppNetFramework.sln

　下図のような感じで、これからアップグレードで行う処理の一覧と現在のステップで行う処理に対する選択肢が表示されます。それぞれのステップで希望する選択肢を選んでいくとアップグレードが完了します。

　それぞれのステップの処理の内容は次の通りです。かなりの定型的作業を自動化してくれます。

1. Back up project：プロジェクトをバックアップする
2. Convert project file to SDK style：csprojファイルを.NET Frameworkの非SDKスタイルから.NETのSDKスタイルに変換する
3. Clean up NuGet package references：パッケージ参照を分析し、packages.configファイルから不要な参照を削除する
4. Update TFM：TFM（ターゲットフレームワークモニカー）を適切なものに更新する
5. Update NuGet Packages：プロジェクトのNuGetパッケージを、必要に応じてステップ4で変更されたTFMをサポートするバージョンに更新する
6. Add template files：テンプレートファイルがある場合に自動で追加する
7. Update Winforms Project：Windowsフォーム固有の処理
   • a．Default Font API Alert：デフォルトフォントが変更されたので、対処が必要であることを、このツールを使っているユーザーに認識してもらうためにツールの画面表示で通知する（アプリのソースコードは変更されない）
   • b．Winforms Source Updater：Program.csに、高DPIモードを設定するSetHighDpiModeメソッドの呼び出しを追加する
8. Upgrade app config files：app.configファイルの内容を更新する
   • a．Convert Application Settings：appsettings.jsonファイルに移行する必要がある設定が存在すれば移行する
   • b．Convert Connection Strings：appsettings.jsonファイルに移行する必要がある接続文字列が存在すれば移行する
   • c．Disable unsupported configuration sections：.NET 6でサポートされない設定が存在すれば無効化する
9. Update source code：ソースコードを更新する
   • a．Apply fix for UA0002: Types should be upgraded：（本ツールで認識できる）更新が必要な型が存在すれば更新する
   • b．Apply fix for UA0012: 'UnsafeDeserialize()' does not exist：.NETでサポートされていない「UnsafeDeserialize()」が存在すれば更新する
10. Move to next project：ソリューション内の次のプロジェクトに移動する

　アップグレードの手順に関する詳細は下記リンクを参照してください。

• https://docs.microsoft.com/ja-jp/dotnet/core/porting/upgrade-assistant-winforms-framework

変換後のソリューションをVisual Studio 2022で開く

　変換後のソリューションをVisual Studio 2022で開くと、下図のように問題がある箇所に警告が出ます。また、自動で変換できなかった箇所に問題がある場合、ビルドするとエラーになります。

　この「警告が出ている箇所」と「ビルドエラーが出る箇所」が手作業で修正が必要な部分なので、集計することで必要な手作業のおおよその作業量が分かります。移行時はこれらの箇所を修正します。

ツールの結果から「必ず手作業が必要になる移行作業」を見積もる

　これまで述べた通り、.NET Portability Analyzerでリストアップされた箇所、.NETアップグレードアシスタントで変換後に警告やビルドエラー発生した箇所は、手作業で修正が必要な箇所となりますが、もう1つ、全機能のテストでグリーンにならなかった箇所も手作業で変更が必要な箇所です。よって、この3つの作業量の合計が「必ず手作業が必要になる移行作業」となります。

　なお、全機能のテストは非常に重い作業なので、自動テストが導入されていない場合、テストにかかるコストを見積もることはできても、そのコストが大き過ぎて問題になることが予想されます。ですが、テストにかかる手間を劇的に削減する方法はないので、以下で説明するように地道に対応する必要があります。

自動テストについて

　古いWindowsフォームアプリの場合、自動テストが導入されていない場合が多く、全機能のテストは非常に負担が大きい作業です。理想的なのはUIとロジックを分離して自動テストを導入することですが、これには大きな手間とコストが必要になり、現実的には一気には導入できない場合もあります。

　ですが、今後の.NETのサポートポリシーでは.NET 6のようなLTSバージョンでもサポートは3年間（2024年11月8日まで）です。次のLTSは.NET 8の予定で、2023年秋のリリース予定です。よって、.NET 8のリリースから.NET 6のサポート切れまで約1年しかありません。

　1年以内で全機能のテストと移行を完了させなければいけない状況から考えると、段階的にでも自動テストできる環境を整えないと今後の継続的なアプリのメンテナンスは不可能になってしまいます。まず、このような状況をステークホルダーにしっかりと説明することが必要です。

　全機能においてUIとロジックを分離し自動テストを導入するのが厳しい場合、まずは手動テストのシナリオをそのまま使い、UIを自動操作することで自動テストを行うことが有効です。後ほどUIとロジックを分離したとしても、UIから行う総合テストとロジック部分をテストする単体・結合テストは別に行うべきものですので、無駄になることもありません。段階的に一部機能だけでもUIとロジックの分離を進め、残りはUIからのテストを行うなどの方法も考えられます。

　Microsoftのツールではないですが、UIを自動操作する（正確には内部APIを呼び出す）ことで、自動テストをする際に有効なツールとして、「Friendly」があります。

　Friendlyについての詳細は下記リンクを参照してください。

• https://github.com/Codeer-Software/Friendly/blob/master/README.jp.md

　このツールを使うことで、Windowsフォーム、WPF（Windows Presentation Foundation）、Win32といったWindowsアプリを簡単にC#のコードで操作できます。導入も非常に簡単なので、全く自動テストが導入されていないアプリに最初に自動テスト導入する際にはとても有効なツールです。

まとめ

　これまで紹介したようなツールを利用することで、.NET Frameworkから.NET 6への移行に関する作業内容、リスク、実施計画、コストは具体化され、それらをまとめた「移行計画」が作成できる“めど”が付けられるようになります。

　また、具体的な移行計画ができれば、例えばWindowsフォームアプリなら.NET 6やそれ以降に移行すべきなのか、それともWebアプリとして再実装すべきなのか、「Power Platform」などのローコードプラットフォームに移行すべきなのかどうかといった検討もより細かい粒度で検討できます。

　.NET Frameworkから.NET 6への移行を検討されており、どこから手を付けてよいかお困りの場合の一助になれば幸いです。