LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

.NET Framework新機能停止から3年、.NET 8移行が問われる背景

「.NET Framework移行」とは、.NET Framework上で稼働するアプリケーションを、現行の.NETへ作り替える取り組みです。.NET FrameworkはWindows専用のランタイムを指します。移行先の代表例が.NET 8で、LTS(長期サポート)版としてサポート終了は2026年11月10日です^*1。

.NET Frameworkは2022年8月にバージョン4.8.1をリリースして以降、新機能や性能改善、新しいC#言語機能への対応が止まっています^*2。Microsoft公式のサポートポリシーでは、.NET Framework 4.5.2以降はWindows OSの構成要素と位置付けられています^*2。サポート期間は、搭載するWindowsのライフサイクルに従うと明記されています^*2。

つまり.NET Frameworkの動作自体はWindowsのサポートが続く限り止まりませんが、独立したサポート終了日は存在しません^*2。稼働するWindows OSがサポート終了を迎えれば、.NET Frameworkのセキュリティ更新も同時に打ち切られる可能性があります。開発を止めた基盤に依存し続けることは、OS更新のタイミングで対応の選択肢を狭める要因になりかねません。

一方、.NET 8は2023年11月14日にリリースされたLTS版で、3年間のサポートが設定され終了日は2026年11月10日です^*1。Microsoftは開発リソースを現行の.NETに集中させており、新しい言語機能や性能改善は.NET Framework側には提供されません^*2。移行の判断を先送りするほど、次に選べるLTS版のサポート残存期間も短くなっていく点に注意が必要です。

ASP.NET CoreとWindows専用機能、.NET Frameworkとの違い

.NET Frameworkから.NET 8への移行で影響範囲が変わるのは、アプリケーションの種類によります^*4。クラスライブラリやコンソールアプリケーションは、変更が小さく済みます。一方、ASP.NET(System.Web)のWebアプリケーションは、ASP.NET Coreへの作り替えが必要で対応量が大きくなります^*4。

デスクトップアプリについては、Windows FormsとWPFがいずれも.NETに存在します^*4。WPF(Windows Presentation Foundation)は、Windows向けのUI構築フレームワークです。両者はオープンソース化され機能拡張が続いていますが、Windows専用の技術である点は変わりません^*4。サードパーティ製コントロールが.NETに未対応のままのケースもあるため、移行前の確認が欠かせません^*4。

Windows専用APIへの依存にも注意が必要です。ネイティブライブラリを呼び出すP/Invokeの仕組み自体は、.NETでも利用できます^*4。ただしuser32.dllやkernel32.dllのようなWindows固有のライブラリを参照している場合、そのコードはWindows上でのみ動作します^*4。レジストリ操作やGDI+描画など、.NET Framework側が提供していたWindows固有の機能を使う箇所もあります^*4。これらは移行前に洗い出す対象になります。

プロジェクトファイルの形式も変わります。.NET Frameworkでは、TargetFrameworkVersion属性を使う旧形式のcsprojファイルが使われていました^*4。パッケージ管理もpackages.configによる方式が中心でした^*4。.NETではSDK形式のcsprojとTargetFramework属性、PackageReferenceによるパッケージ管理に置き換わっています^*4。

比較すると分かるとおり、対応OSとWebフレームワークの差分は書き換えの規模に直結します。ASP.NET CoreへのWeb部分の移行は設定変更だけでは完結せず、実装そのものを見直す作業になる点を踏まえて計画する必要があります^*4。

Remoting・COM+など.NETで使えない機能とCompatibility Packの範囲

.NET Frameworkには存在するものの.NETでは提供されない技術がいくつかあります^*4。具体的には、複数のアプリケーションを分離するApplication Domainsと、プロセスをまたぐ呼び出しに使うRemotingが挙げられます^*4。加えて、サンドボックス機構のCode Access Security(CAS)とSecurity Transparencyも対象です^*4。COM+を扱うSystem.EnterpriseServicesも、.NETでは提供されません^*4。ワークフロー実行基盤のWindows Workflow Foundation(WF)も同様です^*4。

.NET Standard 2.0では「.NET Framework互換モード」が導入されました^*4。この機能により、.NET Framework向けのライブラリを、対象フレームワーク向けにビルドされたかのように参照できます^*4。ただしWPFのAPIを使うライブラリのように対応できないケースもあるため、参照元ライブラリごとに実行時の動作確認が欠かせません^*4。

これらの代替として、Microsoft公式ガイドはApplication Domainsの代わりに別プロセスやコンテナでの分離を挙げています^*4。Remotingの代わりにgRPCやASP.NET Coreを使ったAPI通信、CASの代わりにOSレベルの権限分離も案内されています^*4。WFについては後継のOSSプロジェクトであるCoreWFが代替候補です^*4。

レジストリ操作やGDI+描画のようなWindows固有APIについては、Windows Compatibility Packで対応できる場合があります^*4。これはMicrosoft.Windows.CompatibilityというNuGetパッケージです^*4。.NET Framework相当のAPI surfaceの大部分をカバーします^*4。ただし対応範囲はAPIの種類に依存します^*4。移行前に依存ライブラリを洗い出し、Compatibility Packで解決できる範囲かどうかを個別に確認する作業が欠かせません。

この確認を省いたまま移行を進めると、ビルドは通っても特定の機能だけ動かないケースがあります^*4。実行時例外(PlatformNotSupportedException)で処理が止まる事態も起こり得ます^*4。事前の依存分析を飛ばすことは、移行後の障害対応コストを後工程に先送りすることにほかなりません。

.NET Upgrade AssistantからGitHub Copilotモダナイゼーションへ

.NET Upgrade Assistantは、CLIツールとして提供されてきました^*3。対象は、Windows Forms・WPF・ASP.NET MVC・コンソールアプリ・クラスライブラリです^*3。プロジェクトを分析し、移行作業の一部を自動化する機能を持ちます^*3。

このツールはMicrosoft公式ドキュメント上で非推奨(deprecated)と明記されています^*3。現在はGitHub Copilotモダナイゼーションエージェントが、後継として案内されています^*3。Copilotモダナイゼーションは、プロジェクトを分析して移行計画を作成します^*3。対応するプロジェクトの種類は、ASP.NET・Blazor・Windows Forms・WPF・Azure Functionsなど多岐にわたります^*3。

補助ツールとして、プロジェクトファイルをSDK形式へ変換するtry-convertが用意されています^*4。実行時例外を投げるAPIの使用箇所を検出するPlatform Compatibility Analyzerもあります^*4。移行の標準的な流れは、依存関係の分析、プロジェクトファイル形式の変換、未対応APIの洗い出しと置き換えという順序です^*3。最後にビルド・テストで動作を確認します^*3。

Microsoft公式ドキュメントでは、.NET Upgrade Assistantについて次のように説明されています^*4。「ツール実行後も、アプリの移行完了までにはさらに作業が必要になる」という内容です^*4。移行支援ツールは作業量を減らす手段であり、移行後の動作検証や業務影響の判断は人の手による確認が欠かせません。

内製移行で直面する3つの壁と外注委託時の工数差

.NET Framework移行を内製で進める場合、情報システム部門には複数の専門知識が求められます^*4。第一に、依存ライブラリとAPI使用状況を洗い出す分析力です。第二に、ASP.NET CoreやSDK形式プロジェクトへの実装知識です。第三に、Remoting・CASなど.NETで使えない機能を代替手段へ置き換える設計力です^*4。

これらの知識が不足したまま着手すると、プロジェクト単位で見積もった移行工数が実装段階で膨らみやすくなります。特にASP.NET(System.Web)を使うWebアプリケーションは、プロジェクト形式の変換だけでは完結しません^*4。実装そのものの見直しが必要になる点を、踏まえておく必要があります。

専門パートナーに委託した場合との違いは、依存分析とテストの型化にあります。委託先は複数案件で培った分析手順をチェックリスト化し、未対応APIの洗い出しから代替実装の検証までを標準化した手順で進められる点が特徴です。社内担当者は例外的な業務要件の確認や、移行後の運用設計に専念できる体制になるでしょう。

外注を検討する意義は、移行作業を丸投げすることではなく、依存分析の抜け漏れによる障害対応コストを抑えながら計画どおりに移行を終える点にあります。委託範囲は、依存分析だけを委託する形と、実装・テストまで一括で委託する形で費用感が変わるため、自社の体制と照らして検討するとよいでしょう。

まとめ：.NET Framework移行を計画的に進める3つの判断軸

本稿では.NET Frameworkから.NET 8への移行について、サポート状況・技術差分・移行ツールの3点を整理しました。要点を3つに集約すると次の通りです。第一に、.NET Frameworkのサポートは独立した終了日を持たずWindows OSのライフサイクルに依存するため、待つほど選択肢が狭まります^*2。第二に、ASP.NET Coreへの作り替えやRemoting等の代替実装など、アプリの種類によって対応量が大きく変わります^*4。第三に、移行ツールはGitHub Copilotモダナイゼーションへ主軸が移っており、ツール活用後も人の手による検証が欠かせません^*3。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：Microsoft「.NET and .NET Core – Official Support Policy」（dotnet.microsoft.com）
2. *2　出典：Microsoft「.NET Framework – Official Support Policy」（dotnet.microsoft.com）
3. *3　出典：Microsoft「Upgrade .NET apps overview」（learn.microsoft.com）
4. *4　出典：Microsoft「Port from .NET Framework to .NET」（learn.microsoft.com）

Tweet