.NET Framework→.NET 6モダナイズの初めの一歩「移行計画(手間やコストの見積もり)」の作成に便利なツール:.NET 6移行入門(3)
.NET 6の現状を把握し、具体的な移行方法を学ぶ連載。今回は、「移行計画(手間やコストの見積もり)」の作成に便利なツールについて。
「.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アップグレードアシスタントで自動化可能な作業との関係は次の通りです。
- ソリューション内で.NET 6対応に書き換える必要がある箇所をリストアップ
- .csファイルのアプリコードにおいて移行先でAPIが非サポートのため書き換えが必要な箇所のリストアップ(※1)
→.NET Portability Analyzerで自動化可能 - .csprojファイルの書式や構文が変更されるために書き換えが必要な箇所のリストアップ
→2.の工程で、.NETアップグレードアシスタントで自動変換できるので、この段階でリストアップする必要はない
- .csファイルのアプリコードにおいて移行先でAPIが非サポートのため書き換えが必要な箇所のリストアップ(※1)
- .csprojの書き換え、*.csファイルのアプリコードの書き換え
- 自動で書き換え可能な箇所
→.NETアップグレードアシスタントで自動化可能 - 手動でのみ書き換え可能な箇所(※2)
- 自動で書き換え可能な箇所
- 全機能のテスト
上記の手順とツールによるサポートを考慮すると、「必ず手作業が必要になる移行作業」の作業量を見積もるには、ツールで試験的に移行作業を行い、下記(※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の詳細については下記リンクを参照してください。
.NET Portability Analyzerは下記リンクからダウンロードできます。
注意
2022年3月1日現在、移行先のプラットフォームとして.NET 5までしか対応していません(.NET Frameworkからの移行という観点では移行先を.NET 5に設定して利用しても実害はほとんどありません)。
.NET Portability Analyzerの使い方
Visual Studioの「ツール」→「オプション」で設定画面が表示されます。移行先のプラットフォームを、今回なら.NET 6がまだないので「.NET 5」でチェックします。
Copyright © ITmedia, Inc. All Rights Reserved.
関連記事
- .NETとXamarinの統合、クラウドネイティブ対応はどうなるのか――2021年11月ローンチ、.NET 6の最新情報
既存の.NET Frameworkアプリの.NET 5への移行に関する考慮事項やレガシーアプリのモダナイゼーションについて解説する連載。最終回は、2021年11月ローンチ予定の.NET 6の最新情報について、Microsoft Build 2021の主な発表からお伝えする。 - Microsoft、「Visual Studio 2022 Preview 1」を公開
Microsoftは、次期「Visual Studio」の最初のプレビュー版「Visual Studio 2022 Preview 1」を公開した。メインプロセスが64bit化されており、メモリ不足に陥ることなく、極めて大規模で複雑なソリューションを扱うことが可能だ。 - 「Windows 11 on ARM」の新ABIをMicrosoftが発表、既存アプリの移植が容易に
Microsoftは、Windows 11 on ARMの新ABI「ARM64EC」を発表した。ARM64ECを利用すると、ARMをサポートしていない依存関係やプラグインを含むアプリケーションも、ARM上で動作させることができ、ネイティブARMアプリへと徐々に移行できる。