-
Notifications
You must be signed in to change notification settings - Fork 0
MS_MigrationToDotNet6
- 戻る
- 移行・マイグレーション > 各種、技術毎の移行性 > .NETのクロスプラットフォーム対応
-
.NET Core > .NET 5 > .NET 6 > .NET 8 > .NET 10
- .NET Coreへの移行
- .NET 5への移行
- .NET 6への移行
- .NET 8への移行
- .NET 10への移行
.NET 6(.NET として最初の長期サポート(LTS)版)が
リリースされたので、下に移行情報をサマリしてみた。
補足: 「.NET として最初の LTS 版」は
.NET 6 については正しい(.NET Coreから.NETへ改称された系列で最初の LTS)。
同じ文が .NET 8への移行、
.NET 10への移行 にも書かれているが、
そちらは当てはまらないため、各ページで訂正している。
| # | 対象 | 評価 | 備考 |
|---|---|---|---|
| 1 | Console | 非常に高い | app.config の appsettings.json 化と、その初期化コードを足す程度で移行作業が完了した。 |
| 2 | Windows Forms | 非常に高い | ただし、UI コンポーネント等に互換性があることが前提となる。 |
| 3 | WPF | 非常に高い | ただし、UI コンポーネント等に互換性があることが前提となる。 |
| 4 | ASP.NET Web Forms | - | Core 版は存在せず。 |
| 5 | ASP.NET Core MVC | 中程度 | Console と同様の変更に加え、「脱 System.Web による API 変更」、「新しい DI による構成方法の変更」、「要求処理パイプラインの変更」、「認証周りの API の変更」など、技術的な難易度は少々高いが、コード変更(ポーティング)の手数はそれほど多くならない。 |
| 6 | ASP.NET Core WebAPI | 高い | 技術的には、CORS の構成方法が異なっている以外、前述の MVC と大差はないが、WebAPI は MVC と比べて UI レイヤ ≒ API の I/F 変更の多いフレームワーク レイヤが薄いので、移行の難易度は MVC ほど高くない。また、WebApiCompatShim を使用すると .NET Framework と同じスタイルでインターフェイスを記述できるので移行性は更に高まる。 |
| 7 | ASP.NET Core SPA(ASP.NET Core SPAテンプレート) | 対象外 | 非推奨(Visual Studio + React のスタックの情報より、任意エディタ + CLI ツールのスタックの情報の方がインターネット上の情報が多数ある。) |
移行メモ(原文の表について): 原文はセル結合(
~)で
「非常に高い」「ただし、UI コンポーネント等に…」を 2〜3 行にまたがらせていたが、
GitHub Wiki の表はセル結合に対応しないため、同じ値を展開した。
補足(この評価表が示すもの): 移行の難易度が
**「Windows 固有の基盤にどれだけ依存しているか」**で決まる、
という構図が読み取れる。【易しい】Console / WinForms / WPF → ランタイムを差し替えるだけ。UI は Windows のまま 【中程度】ASP.NET Core MVC / WebAPI → System.Web(IIS 前提の基盤)から離れる必要がある 【不可】 ASP.NET Web Forms → 移行先が存在しない
System.Webからの脱却が Web 系の移行の本体である。
HttpContext.Current、Server.MapPath、Session、ViewStateといった
どこからでも触れるグローバルな仕組みが、
ASP.NET Core では DI で明示的に注入する形に変わっている。
このため「手数は多くないが、考え方の変更が要る」という
原文の評価になる。補足(WebApiCompatShim について): 現在は
提供されていない(ASP.NET Core 3.0 で廃止)。
ApiController互換のスタイルで書けた移行支援パッケージだったが、
現在は素直に ASP.NET Core のコントローラーへ書き換えることになる。
補足(Web Forms の移行先): 原文が「Core 版は存在せず」と
切り捨てているとおり、ASP.NET Web Forms に直接の移行先は無い。
現実的な選択肢は次のいずれかになる。
方針 内容 残す .NET Framework 4.8 のまま維持(.NET Framework 参照) Blazor へ イベント駆動・コンポーネント指向という点で発想が近い MVC / Razor Pages へ Web の標準的な作りに寄せる(実質作り直し) SPA + WebAPI へ フロントを分離する(最も大きな変更) Blazor Server は「サーバー側でイベントを処理し、
差分だけを画面に反映する」という点が Web Forms のポストバックに似ており、
移行先として案内されることが多い。
ただし ViewState や Web Forms のコントロールがそのまま使えるわけではなく、
UI は作り直しになる点は変わらない。
- .NET Framework → .NET 6 モダナイズの初めの一歩
「移行計画(手間やコストの見積もり)」の作成に
便利なツール:.NET 6 移行入門(3) - @IT
https://atmarkit.itmedia.co.jp/ait/articles/2203/25/news003.html
-
.NET が Linux 上でも動作する。
.NET Core 移行と Open 棟梁の .NET Core 対応情報 (2018/04)
https://www.osscons.jp/jovxsnjzb-537/ -
.NET Core2.0 移行の移行性に関する報告 (2018/05)
https://www.osscons.jp/jofbwaon0-537/ -
ASP.NET Core の Linux 開発環境に
ついての考察(WSL or Docker) (2018/05)
https://www.osscons.jp/jotmuz8dq-537/ -
ASP.NET Core のフロントエンド
開発環境に関する考察 (2018/06)
https://www.osscons.jp/jol7cqgyj-537/ -
.NET の暗号ライブラリが進化
している件について。(2018/11)
https://www.osscons.jp/jo0xhcron-537/ -
汎用認証サイト ASP.NET Core 版の
実装が完了しました。(2019/01)
https://www.osscons.jp/jo4cm3lif-537/ -
そう言えば、.NET 5 がアナウンス
されていましたね。(2019/05)
https://www.osscons.jp/jo74jm34c-537/ -
Visual Studio や .NET のバージョンアップの度に
苦しむ Startup クラス修正問題 (2019/09)
https://www.osscons.jp/jo7bdq086-537/ -
.NET Core 3 DesktopPack への移行対応
をしてみた(Open 棟梁)。(2019/11)
https://www.osscons.jp/jo0d1tu6a-537/ -
「Open 棟梁」を .NET Core 3.0 から、
.NET Core 3.1 へアップグレードしてみる。(2020/06)
https://www.osscons.jp/jov00r1c7-537/
-
On Linux
- WSL上での.NET Core開発
- .NET CoreのDockerfile(
MS_DotNetCoreDockerfile.md) - .NET CoreのDockerコンテナ化
-
.NET Coreバージョンアップ(
MS_DotNetCoreUpgrade.md)
- .NET Core on Linux(
DNET_DotNetCoreOnLinux.md)- .NET Core on Linuxのポイント(
DNET_DotNetCoreOnLinux.md) - .NET Coreのインストールとデプロイ(
DNET_DotNetCoreInstallDeploy.md) - ASP.NET Coreのインストールとデプロイ(
DNET_ASPNETCoreInstallDeploy.md)- nginxでASP.NET Coreをホストする(
DNET_nginx.md)
- nginxでASP.NET Coreをホストする(
- .NET Core on Linuxのポイント(
Tags: 移行, .NET開発, .NET Core
このWikiは「Open棟梁Project」,「OSSコンソーシアム 開発基盤部会」によって運営されています。