個人的なメモ

Tomohiro Suzuki @hiro128_777 のブログです。Xamarin に関する事を中心に書いています。 Microsoft MVP for Development Technologies 2017- 本ブログと所属組織の公式見解は関係ございません。

NET Framework から .NET 6 への「移行計画(手間・コストの見積り)」の作成に便利なツール

はじめに

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

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

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

 
参考:.NET 6 の新機能の情報は以下をご覧ください。
hiro128.hatenablog.jp
 
 

移行における最大の障壁

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

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

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

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

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

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

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

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

.NET Portability Analyzer の詳細については以下を参照ください。
docs.microsoft.com
 
.NET Portability Analyzer - Visual Studio 拡張機能は以下よりダウンロードできます。
marketplace.visualstudio.com


注意:
2022/03/01 現在、.NET Portability Analyzerは移行先のプラットフォームとして .NET 5 までしか対応していません。
(なお、.NET Framework からの移行という観点では 移行先を .NET 5 に設定して利用しても実害はほとんどありません。)


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

.NET アップグレード アシスタントの詳細については以下を参照ください。
docs.microsoft.com


.NET アップグレード アシスタントのインストール方法については以下を参照ください。
docs.microsoft.com


一般的な移行で行う作業と、そのうち.NET Portability Analyzer と .NET アップグレード アシスタントが自動で行ってくれる作業との関係は以下の通りです。

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

 
 
上記の手順とツールによるサポートを考慮すると、「必ず手作業が必要になる移行作業」の作業量を見積もるには、実際にツールで試験的に移行作業を行い、
1.1. *.csファイルのアプリコードにおいて移行先でAPIが非サポートのため書き換えが必要な箇所
2.1.  手動でのみ書き換え可能な箇所
について具体的にどのような作業を行う必要があるか精査すればよいことになります。

もちろん、これですべての移行作業が見積もれるわけではありませんが、ツールを利用する前のどこから手を付ければよいかわからない状態に比べて、このようにツールを利用することによって、移行作業を見積もる負荷は大きく下げることができます。
 
 

ツールの利用方法

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

.NET Portability Analyzer と .NET アップグレード アシスタントの利用方法はそれぞれ以下の記事を参照ください。
 

.NET Portability Analyzer

hiro128.hatenablog.jp

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

hiro128.hatenablog.jp
 
 

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

これまで述べた通り、

  • .NET Portability Analyzer でリストアップされた箇所
  • .NET アップグレード アシスタントで変換後に警告やビルドエラー発生した箇所

は、手作業で修正が必要な箇所となりますが、もう一つ、

  • 全機能のテストでグリーンにならなかった箇所

も手作業で変更が必要な箇所となります。

よって、この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 についての詳細は以下を参照下さい。
github.com

このツールを使うことで、Windowsアプリケーション(Windowsフォーム, WPF, Win32)を簡単にC#のコードで操作でき、導入も非常に簡単ですので、全く自動テストが導入されていないアプリケーションに最初に自動テスト導入する際にもとても有効なツールです。