.NET Framework から .NET への移植の概要

2025-06-03

この記事では、.NET Framework から .NET (旧称 .NET Core) にコードを移植する際に考慮すべき事項の概要について説明します。 .NET Framework から .NET への移植は、多くのプロジェクトで比較的簡単です。プロジェクトの複雑さは、プロジェクトファイルの最初の移行後に実行する必要がある作業量を決定します。

ライブラリ、コンソールアプリ、デスクトップアプリなど、.NET でアプリモデルを使用できるプロジェクトでは、通常、ほとんど変更は必要とされません。 ASP.NET から ASP.NET Core への移行など、新しいアプリモデルを必要とするプロジェクトには、より多くの作業が必要です。古いアプリモデルの多くのパターンには、変換時に使用できる同等のパターンがあります。

Windows デスクトップテクノロジ

.NET Framework 用に作成された多くのアプリケーションでは、Windows フォームや Windows Presentation Foundation (WPF) などのデスクトップテクノロジが使用されます。 Windows フォームと WPF はどちらも .NET で使用できますが、Windows 専用テクノロジのままです。

Windows フォームまたは WPF アプリケーションを移行する前に、次の依存関係を検討してください。

.NET 用のプロジェクトファイルでは、.NET Framework とは異なる形式が使用されます。
プロジェクトでは、.NET で使用できない API を使用する場合があります。
サードパーティのコントロールとライブラリが .NET に移植されておらず、.NET Framework でのみ使用できる場合があります。
プロジェクトでは、.NET で使用できなくなったテクノロジを使用します。

.NET では、Windows フォームと WPF のオープンソースバージョンが使用され、.NET Framework に対する機能強化が含まれています。

デスクトップアプリケーションを .NET に移行するチュートリアルについては、次のいずれかの記事を参照してください。

Windows 固有の API

アプリケーションは、.NET でサポートされているプラットフォーム上で引き続き P/Invoke ネイティブライブラリを呼び出すことができます。このテクノロジは、Windows に限定されるわけではありません。ただし、user32.dllや kernel32.dll など、参照しているライブラリが Windows 固有の場合、コードは Windows でのみ機能します。アプリを実行するプラットフォームごとに、プラットフォーム固有のバージョンを見つけるか、すべてのプラットフォームで実行するのに十分な汎用コードを作成する必要があります。

アプリケーションを .NET Framework から .NET に移植する場合、アプリケーションで .NET Framework によって提供されるライブラリが使用されている可能性があります。 .NET Framework で使用できる多くの API は、Windows レジストリや GDI+ 描画モデルなどの Windows 固有のテクノロジに依存しているため、.NET に移植されませんでした。

Windows 互換機能パックは、.NET Framework API サーフェスの大部分を .NET に提供し、Microsoft.Windows.Compatibility NuGet パッケージを介して提供されます。

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

.NET Framework 互換モード

.NET Framework 互換モードは、.NET Standard 2.0 で導入されました。互換モードを使用すると、.NET Standard および .NET プロジェクトは、プロジェクトのターゲットフレームワーク用にコンパイルされたかのように .NET Framework ライブラリを参照できます。ただし、一部の .NET 実装では、他の実装よりも大きな .NET Framework のチャンクがサポートされる場合があります。たとえば、.NET Core 3.0 では、.NET Framework 互換モードが Windows フォームと WPF に拡張されます。ライブラリが WPF API を使用している場合など、.NET Framework ライブラリの参照はすべてのプロジェクトで機能するわけではありませんが、多くの移植シナリオのブロックを解除します。詳細については、「 .NET Framework から .NET にコードを移植するための依存関係の分析」を参照してください。

.NET Framework ライブラリの参照は、どの .NET Framework API が使用されたか、およびこれらの API がプロジェクトのターゲットフレームワークでサポートされているかどうかによって異なるため、すべてのケースで機能するわけではありません。また、一部の .NET Framework API は Windows でのみ機能します。 .NET Framework 互換モードでは、多くの移植シナリオのブロックが解除されますが、プロジェクトをテストして、実行時にも動作することを確認する必要があります。詳細については、「 .NET Framework からコードを移植する依存関係を分析する」を参照してください。

SDK スタイルのプロジェクトでのターゲットフレームワークの変更

前述のように、.NET 用のプロジェクトファイルは、SDK スタイルのプロジェクト形式と呼ばれる .NET Framework とは異なる形式を使用します。 .NET Framework から .NET に移行していない場合でも、プロジェクトファイルを最新の形式にアップグレードする必要があります。ターゲットフレームワークを指定する方法は、SDK スタイルのプロジェクトでは異なります。 .NET Framework では、 <TargetFrameworkVersion> プロパティは、.NET Framework のバージョンを指定するモニカーと共に使用されます。たとえば、.NET Framework 4.7.2 は次のスニペットのようになります。

<PropertyGroup>
  <TargetFrameworkVersion>v4.7.2</TargetFrameworkVersion>
</PropertyGroup>

SDK スタイルのプロジェクトでは、別のプロパティを使用してターゲットフレームワーク ( <TargetFramework> プロパティ) を識別します。 .NET Framework を対象とする場合、モニカーは net で始まり、ピリオドなしで .NET Framework のバージョンで終了します。たとえば、.NET Framework 4.7.2 を対象とするモニカーは net472。

<PropertyGroup>
  <TargetFramework>net472</TargetFramework>
</PropertyGroup>

すべてのターゲットモニカーの一覧については、「 SDK スタイルのプロジェクトのターゲットフレームワーク」を参照してください。

利用できないテクノロジ

.NET Framework には、.NET に存在しないテクノロジがいくつかあります。

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

追加のアプリケーションドメインの作成はサポートされていません。コードを分離するには、別のプロセスまたはコンテナーを別の方法として使用します。
リモート処理

リモート処理は、サポートされなくなったアプリケーションドメイン間の通信に使用されます。プロセス間の単純な通信の場合は、System.IO.Pipes クラスや MemoryMappedFile クラスなど、リモート処理の代わりにプロセス間通信 (IPC) メカニズムを検討してください。より複雑なシナリオでは、 StreamJsonRpc や ASP.NET Core などのフレームワーク ( gRPC または RESTful Web API サービスを使用) を検討してください。

リモート処理はサポートされていないため、デリゲートオブジェクトの BeginInvoke() と EndInvoke() を呼び出すと、 PlatformNotSupportedExceptionがスローされます。
コードアクセスセキュリティ (CAS)

CAS は、.NET Framework でサポートされているサンドボックス手法ですが、.NET Framework 4.0 では非推奨になりました。これはセキュリティの透明性に置き換えられ、.NET ではサポートされていません。代わりに、仮想化、コンテナー、ユーザーアカウントなど、オペレーティングシステムによって提供されるセキュリティ境界を使用します。
セキュリティの透明性

CAS と同様に、セキュリティ透過性サンドボックス手法は .NET Framework アプリケーションでは推奨されなくなり、.NET ではサポートされていません。代わりに、仮想化、コンテナー、ユーザーアカウントなど、オペレーティングシステムによって提供されるセキュリティ境界を使用します。
System.EnterpriseServices

System.EnterpriseServices (COM+) は .NET ではサポートされていません。
Windows Workflow Foundation (WF)

WF は .NET ではサポートされていません。別の方法については、CoreWF を参照してください。

これらのサポートされていないテクノロジの詳細については、「 .NET 6 以降では使用できない .NET Framework テクノロジ」を参照してください。

クロスプラットフォーム

.NET (旧称 .NET Core) は、クロスプラットフォームとして設計されています。コードが Windows 固有のテクノロジに依存しない場合は、macOS、Linux、Android などの他のプラットフォームで実行できます。このようなコードには、次のようなプロジェクトの種類が含まれます。

ライブラリ
コンソールベースのツール
オートメーション
ASP.NET サイト

.NET Framework は Windows 専用コンポーネントです。コードで Windows フォームや WPF などの Windows 固有のテクノロジまたは API を使用する場合、コードは引き続き .NET 上で実行できますが、他のオペレーティングシステムでは実行されません。

ライブラリまたはコンソールベースのアプリケーションを、多くを変更することなくクロスプラットフォームで使用できる可能性があります。 .NET に移植する場合は、これを考慮し、他のプラットフォームでアプリケーションをテストすることができます。

.NET Standard の将来

.NET Standard は、複数の .NET 実装で使用できる .NET API の正式な仕様です。 .NET Standard の背後にある動機は、.NET エコシステムでより高い統一性を確立することでした。 .NET 5 以降では、統一性を確立するための別のアプローチが採用されており、この新しいアプローチにより、多くのシナリオで .NET Standard が不要になります。詳細については、 .NET 5 以降と .NET Standard に関する説明を参照してください。

.NET Standard 2.0 は、.NET Framework をサポートする最後のバージョンでした。

移植を支援するツール

アプリケーションを .NET Framework から .NET に手動で移植する代わりに、さまざまなツールを使用して移行の一部の側面を自動化できます。複雑なプロジェクトの移植は、それ自体が複雑なプロセスです。ツールは、その過程で役立つ場合があります。

アプリケーションの移植に役立つツールを使用する場合でも、この記事の「移植時の考慮事項」セクションを確認する必要があります。

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

.NET アップグレードアシスタントは、さまざまな種類の .NET Framework アプリで実行できるコマンドラインツールです。これは、.NET Framework アプリの .NET へのアップグレードを支援するように設計されています。ツールを実行した後、 ほとんどの場合、アプリは移行を完了するためにより多くの労力を必要とします。このツールには、移行の完了に役立つアナライザーのインストールが含まれています。このツールは、次の種類の .NET Framework アプリケーションで動作します。

Windows フォーム
WPF（Windows Presentation Foundation）
ASP.NET MVC
コンソール
クラスライブラリ

このツールでは、この記事に記載されている他のツール ( try-convert など) を使用し、移行プロセスをガイドします。ツールの詳細については、「 .NET アップグレードアシスタントの概要」を参照してください。

`try-convert`

try-convert ツールは、デスクトップアプリの .NET への移動など、プロジェクトまたはソリューション全体を .NET SDK に変換できる .NET グローバルツールです。ただし、プロジェクトにカスタムタスク、ターゲット、インポートなどの複雑なビルドプロセスがある場合は、このツールはお勧めしません。

詳細については、 try-convert GitHub リポジトリを参照してください。

プラットフォーム互換性アナライザー

プラットフォーム互換性アナライザーは、実行時にPlatformNotSupportedExceptionをスローする API を使用しているかどうかを分析します。 .NET Framework 4.7.2 以降から移行する場合、これらの API の 1 つを見つけることはほとんどありませんが、確認することをお勧めします。 .NET で例外をスローする API の詳細については、.NET Core で例外を常にスローする API を参照してください。

詳細については、「プラットフォーム互換性アナライザー」を参照してください。

移植時の考慮事項

アプリケーションを .NET に移植する場合は、次の推奨事項を順番に検討してください。

✔️ .NET アップグレードアシスタントを使用してプロジェクトを移行することを検討してください。このツールはプレビュー段階ですが、この記事で詳しく説明されているほとんどの手動手順を自動化し、移行パスを続行するための優れた出発点となります。

✔️ まず依存関係を調べることを検討してください。依存関係は、.NET、.NET Standard、または .NET Core を対象とする必要があります。

✔️ NuGet packages.config ファイルからプロジェクトファイル内の PackageReference 設定に移行します。 Visual Studio を使用して、 package.config ファイルを変換します。

✔️ アプリをまだ移植できない場合でも、最新のプロジェクトファイル形式にアップグレードすることを検討してください。 .NET Framework プロジェクトでは、古いプロジェクト形式が使用されます。 SDK スタイルのプロジェクトと呼ばれる最新のプロジェクト形式は、.NET Core 以降用に作成されましたが、この形式は .NET Framework でも機能します。プロジェクトファイルを最新の形式にすることで、将来アプリを移植するための適切な基盤が得られます。

✔️ .NET Framework プロジェクトを少なくとも .NET Framework 4.7.2 に再ターゲットします。これにより、.NET Standard が既存の API をサポートしていない場合に、最新の API の代替手段を利用できるようになります。

✔️ 長期サポート (LTS) リリースである .NET 8 を対象とすることを検討してください。

✔️ Windows フォームおよび WPF プロジェクトの .NET 6 以降をターゲットにしてください。 .NET 6 以降のバージョンには、デスクトップアプリの多くの機能強化が含まれています。

✔️ .NET Framework プロジェクトでも使用できるライブラリを移行する場合は、.NET Standard 2.0 をターゲットにすることを検討してください。 .NET Framework と .NET Standard の両方をターゲットにして、ライブラリをマルチターゲットすることもできます。

✔️ 移行後に不足している API のエラーが発生した場合は、Microsoft.Windows.Compatibility NuGet パッケージへの参照を追加してください。 .NET Framework API サーフェスの大部分は、NuGet パッケージを介して .NET で使用できます。

次の方法で共有

.NET Framework から .NET への移植の概要

Windows デスクトップ テクノロジ