Windows フォームアプリのアップグレードの概要

この記事は、Windows フォームアプリを .NET Framework から .NET にアップグレードする際に何が関係しているのかを理解するのに役立ちます。 Windows フォームは.NETでサポートされており、新しいコントロール、高 DPI の機能強化、アクセシビリティの更新など、積極的な投資を受け取ります。既存のWindows フォームアプリを維持していて、それらの機能強化を利用したり、サポートされている.NETバージョンに移行したりする場合は、この記事が適しています。

この記事では、アップグレードの理由、使用可能なアップグレードパス、およびアップグレードをスムーズに行う準備作業について説明します。また、.NETに相当するものがない.NET Framework テクノロジ、Windows互換機能パックを使用して API ギャップを埋める方法、破壊的変更がアプリに与える影響についても説明します。

アップグレードする方法の例については、「GitHub Copilot のモダナイゼーション機能を使用して Windows フォームアプリを .NET にアップグレードする」を参照してください。

アップグレードの理由

.NET Framework は、機能更新プログラムを受信しなくなったWindows専用のクローズドソースランタイムです。サポートされているバージョンのセキュリティパッチを引き続き受け取りますが、パフォーマンスの向上、言語の改善、.NETのアクティブな投資の恩恵を受けることはできません。 .NET Framework でWindows アプリを維持している場合は、.NETにアップグレードすると、オープンで積極的に開発された、より高速で能力の高いプラットフォームにアクセスできます。

.NETバージョンを最新の状態に保つ方法も重要です。各.NETリリースにはサポート期間が定義されており、サポート外のバージョンで実行されているアプリは、セキュリティパッチと修正プログラムの受信を停止します。サポートが終了する前にアップグレードして、保護を維持します。

.NETでは、ランタイムの起動、スループット、およびメモリ使用量全体でパフォーマンスが有意に向上します。 .NET上のデスクトップアプリは、継続的な機能投資の恩恵も受けられます。

新しいコントロール、アクセシビリティの向上、高 DPI の機能強化。
Windowsとの統合が向上しました。 Windows 11のダークモードなど、一部の機能は.NETでのみ使用できます。
新しい C# およびVisual Basic言語機能とツールの改善。
.NETをターゲットとする NuGet パッケージの豊富なエコシステム。

.NETは、新しいメジャーバージョンを毎年リリースし、長期サポート (LTS) リリースと標準期間サポート (STS) リリースを交互にリリースします。

LTS リリース は 3 年間サポートされており、通常は安定性を優先する運用アプリに最適な選択肢です。
STS リリース は 24 か月間サポートされており、より早く新機能を導入する場合に便利です。

アプリが常にサポートされているバージョンになるように、これらの日付を中心にアップグレード周期を計画します。現在サポートされているバージョンとサポート終了日については、.NETリリース、パッチ、およびサポートを参照してください。

アップグレードパス

ほとんどのアップグレードは、2 つのカテゴリのいずれかに分類されます。アプリに適用されるパスを特定し、この記事のガイダンスとツールを使用して作業を完了します。

.NET Framework から .NET へ: 最も重要な変更。

プロジェクトファイル形式、一部の API、および特定のテクノロジが異なります。開始する前に、前提条件を確認し、依存関係を評価し、API ギャップを計画します。

アプリをビルドして.NETで実行した後、必要に応じて、appsettings.json構成、依存関係の挿入、クラウドサービスなどの新しいパターンを採用できます。これらのパターンの採用は、最新化から.NETまでとは別であり、アップグレードを完了する必要はありません。アイデアとガイダンスについては、「.NET Framework から .NET にアップグレードした後の最新化」を参照してください。
古い.NETバージョンから新しいバージョンへ:より小さなスコープのアップグレード。

主なタスクは、ターゲットフレームワークモニカーの更新、交差するバージョンの破壊的変更の確認、NuGet の依存関係の更新です。

.NET Framework から .NET へのアップグレード

.NET Framework から .NET へのアップグレードは、最も重要なアップグレードパスであり、このセクションの主な焦点です。

Important

.NET はクロスプラットフォームテクノロジですが、.NET 用の Windows デスクトップアプリは引き続き Windows 専用のままです。

1 つの変更は、プロジェクトファイルの形式です。 .NETは SDK スタイルのプロジェクト形式を使用します。これは、従来の形式よりも簡潔です。プロジェクトファイルは SDK スタイルに変換できますが、.NET Framework を対象とします。これにより、実際のポートでの変更の範囲が減り、作業の基準が向上します。

.NETでは、すべての.NET Framework API を使用できるわけではありません。一部の API はサーフェス上に存在しますが、実行時に PlatformNotSupportedException をスローします。 Windows互換性パック (Microsoft.Windows.Compatibility NuGet パッケージ) は、Windows レジストリ、Windows イベントログなどのWindows固有の API へのアクセスを提供することで、これらのギャップの多くを埋めます。詳細については、「Windows互換パックを使用してコードを移植して.NETする」を参照してください。

.NET Framework テクノロジの中には、.NETに相当するものがなく、アプリケーションドメイン、コードアクセスセキュリティ (CAS)、Windows Workflow Foundation などの代替アプローチが必要なものもあります。詳細については、「利用できない .NET Framework テクノロジ」セクションを参照してください。

サードパーティの依存関係を監査します。 .NET Framework のみを対象とするコントロールとライブラリは、.NETでは機能しない可能性があります。 .NET Standard 2.0 または .NET を対象とする NuGet パッケージを優先してください。移植されていないパッケージについては、コミュニティの代替手段を探すか、Windows互換パックに必要な API が含まれているかどうかを確認します。

.NET バージョン間のアップグレード

.NET 9 から .NET 10 など、.NET バージョンから別のバージョンに移行することは、通常、.NET Framework から最新化するよりも小さな作業です。コアタスクは、プロジェクトファイル内の <TargetFramework> プロパティを新しいターゲットフレームワークモニカーに更新することです。たとえば、 net9.0-windows を net10.0-windows に変更します。

ターゲットを更新する前に、交差するすべてのバージョンの破壊的変更に関するドキュメントを確認してください。破壊的変更は、動作、バイナリまたはソースの互換性への影響、デザイン時の動作の変更などです。マイナーバージョンのギャップでも、アプリに影響を与える変更が発生する可能性があります。 .NETの破壊的変更を確認し、アップグレードするバージョン範囲にフィルターを適用します。

ターゲットフレームワークを更新した後、NuGet の依存関係を更新します。古い.NETバージョンを対象とするパッケージには、現在のランタイムを利用する新しいリリースが含まれている場合があります。更新プログラムを確認し、移行先のバージョンを対象とするパッケージを優先します。一部のパッケージでは、API が非推奨になったり、新しいバージョンで動作が変更されたりする場合があるため、更新時にリリースノートを確認してください。

GitHub Copilot アプリの最新化

GitHub Copilotモダン化エージェントは、Windows フォームおよびWPFアプリをアップグレードするための推奨されるツールです。これは、アップグレードプロセス全体を処理する、GitHub Copilotに組み込まれた AI を利用したエンドツーエンドのエクスペリエンスです。

エージェントは、次の 3 段階のワークフローに従います。

評価。 Copilotは、プロジェクトの構造、依存関係、およびコードパターンを調べます。破壊的変更、API の互換性の問題、非推奨のパターン、および全体的なアップグレードスコープを特定します。次に、続行する前に確認できるように、アップグレード順序や互換性処理などの戦略の決定を示します。
プランニング。 Copilot、評価と確認された選択肢を詳細なアップグレード計画に変換し、アップグレード戦略、リファクタリングアプローチ、依存関係パス、リスク軽減策を文書化します。
実行。 Copilot は、計画を検証基準付きの順次タスクに分解し、コード修正を適用して、変更を段階的にコミットします。自動的に解決できない問題が発生した場合は、ヘルプを要求し、修正から学習します。

すべてのアップグレード状態はリポジトリの .github/upgrades/ に格納されるため、セッション間で一時停止および再開したり、開発環境を切り替えたりすることができます。

エージェントは、次のアップグレードパスをサポートしています。

.NET Framework (任意のバージョン) から .NET 8 以降
.NET Core 1.x~ 3.x から .NET 8 以降
.NET 5～7 から .NET 8 以降へ
Azure サービスへの移行

Visual Studio 2026、Visual Studio 2022 17.14.16 以降、Visual Studio Code、GitHub CLI で使用できます。 Visual Studioでアップグレードを開始するには、ソリューションエクスプローラーでソリューションまたはプロジェクトを右クリックし、[最新化] を選択するか、GitHub Copilot Chat ウィンドウを開き、「@Modernize」と入力します。 Visual Studio Codeで、GitHub Copilot Chat パネルを開き、「@modernize-dotnet」と入力します。

セットアップと使用状況の詳細については、「GitHub Copilotモダン化とは」を参照してください。

使用できない .NET Framework テクノロジ

いくつかの.NET Framework テクノロジには、.NETに相当するものがなく、新しいランタイムでアプリを実行する前に別の方法が必要です。移行作業の最も破壊的なカテゴリを表しているため、アプリがこれらのテクノロジのいずれかに早期に依存しているかどうかを特定します。完全なリファレンスについては、.NET で利用できない .NET Framework テクノロジを参照してください。

アプリケーションドメイン

AppDomainはサポートされていません。動的アセンブリの読み込みには AssemblyLoadContext を使用し、分離には個別のプロセスまたはコンテナーを使用します。一部の AppDomain API メンバーは存在しますが、実行時に PlatformNotSupportedException をスローします。
リモート処理

.NETリモート処理はサポートされていません。ローカル IPC にはSystem.IO.PipesまたはMemoryMappedFileを使用し、マシン間通信には gRPC と ASP.NET Coreを使用します。デリゲートオブジェクトに対して BeginInvoke() と EndInvoke() を呼び出しても、PlatformNotSupportedException がスローされます。
コードアクセスセキュリティ (CAS)

CAS はサポートされておらず、セキュリティ境界ではなくなりました。代わりに、仮想化、コンテナー、ユーザーアカウントなどの OS レベルのセキュリティ境界を使用してください。
セキュリティの透明性

セキュリティで保護されたコードをセキュリティクリティカルなコードから分離したセキュリティの透明性は、セキュリティ境界としてサポートされなくなりました。 CAS と同様に、この機能は、.NETが提供しないランタイムの適用に依存していました。代わりに OS レベルの分離メカニズムを使用してください。
Windows Workflow Foundation (WF)

WF は .NET ではサポートされていません。アプリでワークフローをホストまたは使用する場合は、.NETを対象とする Windows Workflow Foundation ランタイムのオープンソースポートである CoreWF を検討してください。
System.EnterpriseServices (COM+)

System.EnterpriseServicesはサポートされていません。オブジェクトプール、トランザクション、ロールベースのセキュリティなどの COM+ サービスを使用するアプリ System.EnterpriseServices 、代替手段を使用するように再設計する必要があります。分散トランザクションの場合は、 System.Transactionsを検討してください。サービスホスティングシナリオの場合は、ASP.NET Coreまたは worker サービスを検討してください。

これらの領域の一部の API は.NETに存在しますが、コンパイル時に失敗するのではなく、実行時にPlatformNotSupportedExceptionをスローしていることに注意してください。移行の早い段階で.NETアプリをテストして、完全なポートに投資する前にこれらの問題を解決します。

.NET Framework からのアップグレードを開始する前に

.NETへのアプリの移植を開始する前に、一連の準備手順を実行しますが、プロジェクトは引き続き .NET Framework を対象としています。この基礎作業を行うと、最初に実際のアップグレード中に変更の範囲が減り、よりクリーンで検証されたベースラインを開始できます。完全なリファレンスについては、「.NET Framework からコードを移植するための前提条件」を参照してください。

ツールをアップグレードします。

ターゲットにする.NETのバージョンをサポートするバージョンのVisual Studioを実行していることを確認します。新しい SDK バージョンには、移行サポートの強化、アナライザーの向上、および更新されたプロジェクトテンプレートが含まれます。 .NET SDK、MSBuild、Visual Studio バージョン間の関係については、「.NET SDK、MSBuild、およびVisual Studioのバージョン管理の関係」を参照してください。
ターゲット .NET Framework 4.7.2 以降。

移植する前に、プロジェクトを .NET Framework 4.7.2 以降に再ターゲットします。このバージョンでは、.NET Standard 2.0 と最も広範な API 互換性面が提供されるため、アップグレード中に発生する API ギャップの数が減ります。

Visual Studioでプロジェクトを右クリックし、[プロパティ] を選択し、[ターゲットフレームワーク] ドロップダウンを .NET Framework 4.7.2 に変更します。続行する前に、問題を再コンパイルして修正します。
PackageReference 形式に変換します。

プロジェクトで packages.config ファイルを使用して NuGet 参照を管理する場合は、 PackageReference 形式に移行します。 PackageReference は最新のアプローチであり、次の手順で採用する SDK スタイルのプロジェクト形式に直接統合されます。

Visual Studioで、ソリューションエクスプローラーでpackages.configを右クリックし、[packages.config を PackageReference に移行] を選択します。移行の出力を確認し、続行する前に警告を解決します。
SDK スタイルのプロジェクト形式に変換します。

プロジェクトファイルを SDK スタイルの形式に切り替えます。 SDK スタイルのプロジェクトは、より簡潔で、マルチターゲットをサポートし、.NETに必要です。この変換は、.NET Framework をターゲットにしながら実行できるため、安全な準備手順です。多くの変換ツールはこれを自動的に処理するか、プロジェクトファイルの内容を SDK スタイルの同等の内容に置き換え、必要なプロパティを再追加することで手動で変換できます。
NuGet の依存関係を更新します。

すべての NuGet パッケージを最新バージョンに更新し、.NET Framework のみを対象とするパッケージではなく、Standard 2.0 .NET対象のパッケージを優先します。これにより、ターゲットフレームワークを変更するときの依存関係の阻害要因のリスクが軽減されます。新しいバージョンで導入された重大な変更については、パッケージのリリースノートを確認してください。

上記の提案はすべて、.NETにアップグレードする前にプロジェクトが適切な状態であることを確認します。

Windows 互換機能パック

.NET Framework からの移植に関する最も一般的な問題の 1 つは、API が不足しています。 .NET Standard では、Windows レジストリ、WMI、リフレクション出力など、すべてのプラットフォームで動作しないテクノロジが意図的に除外されるため、これらの API は既定では使用できません。 Microsoft.Windows.Compatibility NuGet パッケージはそのギャップを埋めます。次のテクノロジ領域で約 20,000 個の API が提供されます。

Windows レジストリ
Windows イベントログ
Windows Management Instrumentation (WMI)
Windows パフォーマンスカウンター
ディレクトリサービス
Windows アクセス制御リスト (ACL)
Windows サービス
Windows 暗号化
Windows Communication Foundation (WCF)
ポート、ODBC、CodeDom など

このパックは、.NET Standard 2.0 の上に配置され、増分的に最新化する場合に特に便利です。これにより、最初から Windows 固有の API の使用箇所を書き換えなくても、まずアプリを .NET 上でビルドして実行できるようにし、その後でより踏み込んだリファクタリングに取り組めます。

プロジェクトに追加するには、 Microsoft.Windows.Compatibility NuGet パッケージをインストールします。

dotnet add package Microsoft.Windows.Compatibility

詳細については、「Windows互換パックを使用してコードを.NETに移植する」を参照してください。

破壊的な変更

破壊的変更は、.NET Framework から移植する場合でも、.NET バージョン間を移動する場合でも、アップグレードの期待される部分です。事前に確認しておくことで、移行の後半で想定外の問題が発生するのを防げます。完全なリファレンスについては、「コードの移植時の破壊的変更」を参照してください。

破壊的変更は複数のカテゴリに分類され、すべての変更でコンパイル時エラーが発生するわけではありません。

動作の変更 は、実行時の API の動作に影響します。シグネチャは変わりませんが、出力、スローされた例外、または内部動作が変更されます。ビルドエラーが発生しないため、これらはキャッチするのが最も困難です。
バイナリ互換性 の変更は、既存のコンパイル済みアセンブリが再コンパイルなしで動作し続けるかどうかに影響します。パブリック API サーフェスを削除または変更すると、バイナリの互換性が切断されます。
ソース互換性 の変更では、新しいバージョンに対して正常にコンパイルされる前にソースコードを変更する必要があります。
デザイン時の互換性の変更は、Visual Studioまたはその他の設計環境でのプロジェクトの開き方と動作に影響します。

.NET Framework から移植する場合は、大きなバージョンのギャップを越えているので、潜在的な変更の一覧が長くなります。 .NET バージョン間 (たとえば、.NET 6 から .NET 9) 間でアップグレードする場合、スコープは狭くなりますが、その間のすべてのバージョンで、アプリに影響を与える変更が生じる可能性があります。ターゲットバージョンだけでなく、スキップする各バージョンの破壊的変更を確認します。

Windows フォームに固有の破壊的変更については、「.NET Framework から.NETへの移行に関する破壊的変更」を参照してください。アップグレードするバージョン範囲への破壊的変更参照をフィルター処理し、アプリで使用する API に適用されるエントリを確認します。

アップグレード後のタスク

アプリがビルドされ、.NETで実行されたら、いくつかのクリーンアップタスクを完了して、アップグレードから残った成果物を削除します。

NuGet パッケージを確認します。

アップグレードプロセスでは、パッケージが新しいバージョンに更新されている可能性があります。これらの新しいバージョンの一部では、以前のバージョンで必要な依存関係が削除されます。アップグレード後、更新された各パッケージを確認し、不要になった推移的な依存関係を削除します。ビルドエラーを引き起こさない動作の変更をキャッチするために、更新されたパッケージのリリースノートを確認します。

古い NuGet 成果物をクリーンアップします。

プロジェクトで nuGet 参照を管理するために packages.config ファイルを使用した場合、 PackageReference 形式に移行した後は不要になります。プロジェクトから削除します。プロジェクトまたはソリューションディレクトリ内のローカル packages フォルダーを削除することもできます。NuGet では、ユーザープロファイルの .nuget\packages にあるグローバルキャッシュフォルダーにパッケージが格納されるようになりました。

System.Configuration参照を更新します。

ほとんどの.NET Framework アプリは、System.Configurationを直接参照します。アップグレード後も、プロジェクトにその参照が含まれる場合があります。 System.Configuration ライブラリは、実行時の構成のために app.config ファイルから読み取ります。 .NETで、直接フレームワークアセンブリ参照なしで同じ API サーフェスを提供する System.Configuration.ConfigurationManager NuGet パッケージに置き換えます。

アップグレード後に最新化する

.NETでアプリを実行したら、.NET Framework では使用できない最新のパターンを採用できます。アップグレードを完了するためにこれらの変更は必要ありませんが、保守性が向上し、.NETへの積極的な投資を利用します。より広範なアイデアについては、「.NET Framework から .NET にアップグレードした後の最新化」を参照してください。

App.config から appsettings.jsonに移行します。

.NET Framework では、接続文字列やログ構成などの実行時設定に App.config が使用されます。 .NETアプリでは、通常、Microsoft.Extensions.Configurationによって提供されるappsettings.jsonが代わりに使用されますNuGet パッケージ。ロギングプロバイダーを含む多くのライブラリでは、App.config のサポートを終了し、代わりに appsettings.json を使用するようになりました。移行すると、アプリがエコシステムに合わせて調整され、新しい依存関係を追加する際の構成が簡略化されます。

App.config ファイルは、System.Configuration.ConfigurationManager NuGet パッケージを通じて.NETで引き続き機能するため、段階的に移行できます。ガイダンスについては、「.NETの構成」を参照してください。

WebBrowser コントロールを WebView2 (WPF) に置き換えます。

WebBrowser コントロールは、サポートされなくなったInternet Explorerに基づいています。 .NETのWPFは、代わりにMicrosoft Edgeに基づいてWebView2 コントロールを使用できます。 WebView2 は、パフォーマンス、セキュリティ、および Web 標準のサポートを強化した、最新のアクティブに維持されたブラウザーコントロールを提供します。

Microsoft.Web.WebView2 NuGet パッケージをプロジェクトに追加します。ユーザーが実行するWindowsのバージョンによっては、WebView2 ランタイムを個別にインストールすることが必要になる場合があります。詳細については、「Microsoft Edge WebView2 の概要」を参照してください。

フィードバック

このページはお役に立ちましたか?

Last updated on 2026-06-26