.NET Framework→.NET移行の事前チェックリスト
結論
.NET Frameworkから.NETへの移行で本当に大事なのは、実装に入る前の棚卸しです。
- 移行前に .NET Framework側を整理する（4.7.2以上、できれば4.8.1へ）
- 難易度はコード量よりアプリモデルで決まる
- WinForms/WPFは.NETに移行できるがWindows専用のまま
- ASP.NET Framework → ASP.NET Coreは実質アーキテクチャ移行
- WCFとEF6はランタイム移行と切り離せる
- AppDomain作成、.NET Remoting、BinaryFormatter依存などは赤信号（先に見つけないと工数が爆発）
今すぐ移行すべきかの判断
.NET Frameworkに残る選択もあり得る
.NET Framework 4.8.1はサポートされているWindowsに載っている限り継続サポートされます。残留が妥当なケース：
- Web Formsの画面資産が大量にある
- WCFサーバー互換を厳密に保つ必要がある
- サードパーティ部品がmodern .NET非対応
- ビジネス的に大きな仕様変更が許されない
選択肢ごとの比較
| 選択 | 良くなること | 残る制約 |
|---|---|---|
| .NET Framework 4.8.1に留まる | 既存資産を崩さず安定運用 | Windows専用、古いアプリモデル |
| modern .NETに移行（Windowsに留まる） | ランタイムやツールチェーンをmodern化 | Windows API依存は残る |
| modern .NET + Linux/コンテナも視野 | 配置先の自由度向上 | Windows専用APIを先に剥がす必要あり |
着手前の4つの方針決定
- 着地点の.NETバージョン：2026年3月時点では .NET 10がLTS。新規移行は現行LTSが基本
- Windows専用のままか、クロスプラットフォームか：Linux化を狙うなら
System.Drawing、レジストリ、WMIなどを棚卸し - 一括か段階移行か：ASP.NET Frameworkなら段階移行が安全
- 今回の移行対象から外すもの：ランタイム移行とORM/認証/クラウド移行は分離する
着手前に整える土台（Microsoft公式推奨）
- .NET Framework 4.7.2以降へ上げる（できれば4.8.1）
- PackageReferenceへ寄せる（
packages.configからの移行） - SDKスタイルプロジェクトへ変換
- 依存関係を最新バージョンへ更新
注意：packages.config→PackageReference移行では、ASP.NETプロジェクトで制約あり。XDT変換（web.config.install.xdt）は適用されない。
プロジェクト種別ごとの難易度
| 種別 | 難易度 | 主な論点 |
|---|---|---|
| クラスライブラリ | 低〜中 | API互換性、依存関係 |
| コンソール/Windows Service | 低〜中 | 配布方式、ネイティブ依存 |
| WinForms/WPF | 中 | Windows専用のまま、サードパーティUI |
| ASP.NET MVC/Web API | 中〜高 | ASP.NET Coreへのapp model移行 |
| ASP.NET Web Forms | 高 | 画面モデルの差が大きい |
| WCFクライアント | 中 | パッケージ置き換え |
| WCFサーバー | 高 | CoreWCFかgRPC再設計か |
| EF6→EF Core同時実施 | 高 | ORMが別物 |
.NETで使えない技術（赤信号）
| 技術 | 状態 | 対応 |
|---|---|---|
| AppDomain.CreateDomain | 非対応 | AssemblyLoadContextや別プロセスで |
| .NET Remoting | 非対応 | gRPC/HTTP/IPCへ再設計 |
| CAS | 非対応 | OS/コンテナの権限分離で |
| COM+ | 非対応 | 設計を分離・置換 |
| Workflow Foundation | 非対応 | CoreWFなど別見積もり |
| BinaryFormatter | .NET 9以降で常に例外 | シリアライザー移行必須 |
共有ライブラリの切り方
- 純粋な業務ロジックから先に移す（計算、ルール判定、DTOなど）
netstandard2.0は今でも有効な橋（.NET Framework側とも共存できる）- ライブラリは leaf-first（葉から順に）上げる
- ASP.NET系ライブラリは
System.Web依存を剥がせるかが勝負
一度に全部やらない
特に避けたい同時実施：
- ランタイム移行 + ORM総入れ替え
- ランタイム移行 + 認証基盤変更
- ランタイム移行 + クラウド全面移行
- ランタイム移行 + UIフレームワーク刷新
現実的な移行の進め方
- 現行Framework側を整える（4.8.1化、依存関係更新、PackageReference化）
- shared libraryを先に救出する（netstandard2.0またはmulti-target）
- アプリ本体はapp modelごとに戦略を変える
- テストとベースラインを取ってから動く
まとめ
- 移行前に .NET Framework側を整理する
- アプリモデルごとに難易度を分ける
- 使えない技術を先に洗う
- Windows専用前提をどこまで許容するか決める
- ORM、認証、クラウド移行を同時に盛りすぎない
関連する記事
同じタグを共有する最新の記事です。さらに近い話題で知識を深められます。
シリアル通信アプリ開発の落とし穴
シリアル通信アプリで詰まりやすいフレーミング、複数タイムアウト、RTS/CTS や DTR、USB 変換時の再接続、UI フリーズ回避、single writer 設計、生ログまで、実装前に押さえたい論点を実務目線で整理した解説記事です。
C#をNative AOTでDLL化しC/C++から呼び出す方法
C# のクラスライブラリを Native AOT でネイティブ DLL として発行し、UnmanagedCallersOnly で C/C++ から呼び出す構成を、設計指針・最小実装・はまりどころまでまとめて整理した実務向け解説記事です。
デスクトップアプリにGeneric Hostを導入する
WPF や WinForms の常駐アプリで、起動・停止・例外処理・定期処理が UI に染み出してきたら読みたい記事。Generic Host と BackgroundService を導入して責務を整理し、graceful shutdown まで設計に組み込む考え方を、最...
ActiveX/OCXの残す・包む・置き換える判断表
ActiveX や OCX をどう扱うか迷ったときに、残す・包む・置き換えるの三択を 32bit / 64bit やブラウザ依存、ベンダー保守、登録手順まで含めて整理する判断表と移行チェックリストをまとめた記事です。
FileSystemWatcherの安全な使い方
FileSystemWatcher のイベントは完了通知ではないという前提に立ち、取りこぼし、重複通知、完了判定の落とし穴を整理し、再スキャン要求への畳み込み、原子的 claim、idempotency までの設計指針をまとめます。
関連トピック
このテーマと近いトピックページです。記事を起点に、関連するサービスや他の記事へ進めます。
Windows技術トピック
Windows 開発、不具合調査、既存資産活用の技術トピックをまとめた入口です。
このテーマがつながるサービス
この記事は次のサービスページにつながります。近い入口からご覧ください。
Windowsアプリ開発
業務アプリ、装置連携、通信ツールなどの Windows ソフト開発を支援します。
既存Windowsソフトの改修・保守
既存 Windows ソフトの機能追加、保守、段階的モダナイゼーションを支援します。