將 .NET Framework 遷移到 .NET 之前該確認的事 - 在著手前就決定勝負的實戰檢核表

附中文工作表的 Excel 檢核表下載

把 .csproj 的 TargetFramework 改成 net10.0，更新幾個 NuGet，build 通過就結束。

……這種遷移相當和平。實際上不是那樣的情況更多。

.NET Framework 的現場有 System.Web、WCF、Web Forms、舊的 packages.config、web.config.install.xdt、原生 DLL、COM / ActiveX、只在設計時動作的第三方控制項、隱含的 x86 前提、依賴設計工具的 ResX、舊的序列化器等，平時沒意識到的前提相當隱藏著。

所以 .NET Framework 到 .NET 遷移真正重要的是在實作前的盤點。 如果著手前能拆解論點，遷移就不是「大賭注」而是「依序解決的作業」。

本文整理在把既有的 .NET Framework 4.x 的業務應用程式 遷移到 目前的 .NET 之前，該確認什麼。主要對象如下。

• 類別庫
• 主控台應用程式
• Windows 服務
• WinForms / WPF
• ASP.NET Framework（MVC / Web API / Web Forms）
• 使用 WCF 的應用程式
• 使用 EF6 的應用程式

撰寫時點為 2026-03-15。支援期間或官方工具的建議會改變，如果時間相差較久閱讀，請一併確認官方資訊。

1. 先講結論

先放不易偏離的結論。

• 在遷移前整理 .NET Framework 側 為先。Microsoft 的官方指南也推薦在移植前把版本提升到 .NET Framework 4.7.2 以上，先完成 PackageReference 化、SDK 樣式化、相依關係更新。
• 難度由 應用程式模型而非程式碼量 決定。類別庫或主控台相對輕，ASP.NET Framework、Web Forms、WCF 伺服器、WF 容易變重。
• WinForms / WPF 即使遷移到 .NET 仍然是 Windows 專用。這裡誤解就會踩到「遷移後卻裝不上 Linux 容器」的經典地雷。
• ASP.NET Framework → ASP.NET Core 實質上是架構遷移。小規模應用程式有時能一口氣過，但大型正式系以分段遷移為前提較安全。
• WCF 和 EF6 可能與 runtime 的遷移切離。WCF 用戶端有 .NET 用的受支援套件，EF6 則可以在遷到 modern .NET 後再分離遷移到 EF Core。
• 另一方面，AppDomain 建立、.NET Remoting、CAS、COM+、Workflow Foundation、BinaryFormatter 依賴 是紅燈。不先發現，後方工時會爆發。
• packages.config / install.ps1 / XDT / content 資產 / 原生 DLL / COM / ActiveX / x86 前提 即使 build 通過，執行時或設計時也容易掉，著手前要盤查。
• 2026-03 時點 .NET 10 是 LTS。新遷移的著地點基本以 現行 LTS 為基準思考是自然的。
• 沒準備測試、計測、回滾的遷移很危險。遷移不如說比起實作作業，更是把前提條件一個一個可視化的作業。

2. 先決定「是否現在就該遷移」

最先該做的不是思考「遷移的方法」。 是決定 這個應用程式現在真的該遷移嗎。

這裡曖昧，容易變成技術上正確但事業上過重的遷移，或相反明顯該遷移卻拖太晚的判斷。

2.1 留在 .NET Framework 的判斷也可能存在

.NET Framework 4.8.1 只要載於受支援的 Windows，就會持續受支援。也就是說，並非馬上全部 modern .NET 否則立即危險 這種單純話題。

但留下有明確的限制。

• 出不了 Windows 專用
• 持續抱著 ASP.NET Web Forms 或舊伺服器堆疊
• 難以受新的 .NET 的效能改善、語言功能、生態系恩惠
• 容易與雲、容器、CI/CD 的現代前提偏離

相反，強烈依賴下列事項的話，暫時靠向 .NET Framework 4.8.1 穩定運營，另行計畫替換 是合理的。

• Web Forms 的畫面資產大量
• 需要嚴密維持 WCF 伺服器相容
• Workflow Foundation 或 COM+ 依賴深
• 第三方的設計時部件不支援 modern .NET
• 事業上不允許大規模規格變更

2.2 各選項會改變什麼

重要的是不是 想不想遷移，而是先決定 遷移後想著地在哪。

3. 該先決定的 4 個方針

3.1 著地點的 .NET 版本

撰寫時點，Microsoft 的支援政策上 .NET 10 是 LTS。 另一方面 .NET 8 LTS 和 .NET 9 STS 都預定在 2026-11-10 結束支援。

所以，這之後要新從 .NET Framework 遷移的話，沒什麼特殊原因的話 以現行 LTS 為著地點 自然。

這裡實務的想法簡單。

• 想短期結束的小遷移 直接著地在現行 LTS
• 長期運營前提的基幹系統 也基本以現行 LTS 思考
• 「因既有函式庫的情況想用前 1 個 LTS」作為情況可以有，但 用日期看到什麼時候會維護 來判斷

3.2 繼續 Windows 專用，還是將來瞄準跨平台

這個判斷，該看的論點會相當變。

• 繼續 Windows 專用 的話，可以走用 WPF / WinForms 或 Windows Compatibility Pack，先把 runtime 現代化的現實路線。
• 也想瞄準將來 Linux / 容器化 的話，需要在早期階段盤點 System.Drawing.Common、登錄、WMI、EventLog、Windows Service、COM、Office Interop 等 Windows 前提的 API。

不決定這個開始遷移，中途會有「Windows 固定就好嗎」「不對，本來想裝到容器的」這樣話題扭曲。

3.3 一次做還是分段遷移

遷移的形式大致 3 種。

• 接近 in-place 的一併遷移
• 並列新舊的 side-by-side 遷移
• 以 route / library 單位一點點靠的分段遷移

特別 ASP.NET Framework 應用程式，Microsoft 的指南也明確介紹 incremental migration。 不想停正式、功能數多、周邊依賴多的條件下，從一開始以分段遷移為前提設計比較無勉強。

3.4 決定什麼 「不放入本次遷移對象」

遷移容易失敗是因為堆太多事做。

例如同時做下列容易變重。

• .NET Framework → .NET
• ASP.NET Framework → ASP.NET Core
• EF6 → EF Core
• Windows 伺服器 → Linux 容器
• 認證基礎變更
• 日誌 / 監視基礎變更
• 資料庫的遷移

當然全部遲早可能必要。 但 是否需要同時做 是另一回事。

現實上如下分開比較成功。

1. 先現代化 runtime 和專案結構
2. 在那之上遷移 app model
3. 最後更新 ORM、認證、雲、監視

4. 著手前該備好的基礎

Microsoft 的移植前指南相當實務。 簡言之，在遷移前先讓現在的 .NET Framework 專案靠到現代的入口。

4.1 提升到 .NET Framework 4.7.2 以上

官方指南推薦移植前以 .NET Framework 4.7.2 以上 為目標。 理由是 .NET Standard 即使沒有直接保留既有 API，也更容易靠向更新的 API 替代。

實務上，可能的話以 4.8.1 為基準思考比較易懂。

• 支援觀點上自然
• 作為 .NET Framework 側的最終穩定點易處理
• 容易建立「先在現行 Framework 側整理」的方針

先做這個會改變什麼

• .NET Standard 2.0 共用函式庫的處理容易穩定
• 能先減少舊 runtime 來的雜訊
• 容易區分相容性問題的原因是「Framework 的舊」還是「modern .NET 化」

4.2 靠向 PackageReference

移植前指南推薦把參照靠向 PackageReference 形式。 先做這個，相依關係管理會透明許多。

PackageReference 化會改變什麼

• 套件參照集中到 csproj
• 傳遞相依關係容易看
• restore 的前提對齊 modern .NET 側
• 與 CLI / CI 的相性好

但這裡有地雷。

典型地雷

NuGet 的官方文件明記從 packages.config 到 PackageReference 的遷移有以下限制。

• Visual Studio 內建遷移在 ASP.NET 專案中不能用
• 依賴 install.ps1 / uninstall.ps1 的套件可能不如預期動作
• content 資料夾的資產有時被忽視
• XDT 變換（例如 web.config.install.xdt）不會套用
• lib 直下的組件構成舊的套件可能無法好好解析

也就是說，只是變套件格式 這種想法不可取。 特別 classic ASP.NET 在 NuGet 套件安裝時有改寫 web.config 的文化，遷移時隱藏前提容易露出。

4.3 靠向 SDK 樣式

移植前指南也推薦轉換為 SDK 樣式的專案格式。

這相當有效。

SDK 樣式化會改變什麼

• csproj 大幅簡潔
• 與 PackageReference 相性好
• 容易 multi-targeting
• 容易靠向以 dotnet build / dotnet test / dotnet publish 為中心的 CI/CD
• 接近 modern .NET 側的構成，後半的差減少

反之，帶著舊 csproj 和舊 NuGet 管理直接跳 modern .NET，差異太大。

4.4 先更新相依關係

也依官方指南，相依關係往 可用的最新版本 靠，可能就靠到 支援 .NET Standard 的版本。

先做這個的意義

• 能早知道「這個套件能在 modern .NET 用嗎」
• 防止舊相依關係成為雜訊
• 容易把 shared library netstandard2.0 化
• 容易讓後段遷移作業聚焦在「程式碼移植」

4.5 也確認官方工具的前提

2026-03 時點，Microsoft 的引導重心移到 GitHub Copilot 現代化 側。 也就是說比起只以過去的遷移支援工具為前提，看作包含評估、規劃、程式碼修正、驗證的一連串支援流程較符合實務。

但現行文件前提是 Visual Studio 2026 或仍受支援的 Visual Studio 2022 系、GitHub Copilot 和 C# 程式碼。

這個確認必要的理由

• 對官方工具能期待什麼會改變
• 能對齊團隊的 IDE / build agent / 擴充功能的前提
• 能判斷 VB.NET 解決方案中不要過度期待自動化

VB.NET 混在的現場不罕見。 所以「最新官方工具能幫到哪」在最初確認有價值。

5. 各專案類別估算難度

遷移常被以「從 .NET Framework 到 .NET」一併談，但現實上 各專案類別是不同的遊戲。

5.1 大致的難度感

5.2 類別庫「共用邊界」如何切是關鍵

類別庫相對容易遷移。 但那僅限於 函式庫真正函式庫式分離時。

有以下相依難度就上升。

• 有觸 System.Web
• 直接看 HttpContext.Current
• 公用 API 含 WPF / WinForms 的型別
• 過度倚賴登錄、WMI、EventLog 等 Windows API
• 依賴 AppDomain 或 Remoting

看作 只切出商務邏輯則輕，抱有 app model 就重 比較易懂。

5.3 WinForms / WPF 容易遷移但繼續 Windows 專用

WinForms 和 WPF 能遷移到 .NET。 但兩者都 繼續是 Windows 專用框架。

這裡搞錯期待值很危險。

• 會變好的
  • 能上 modern .NET 的 runtime、語言、SDK 樣式
  • 容易靠向現代的 CI/CD 或 package 管理
  • 容易得到部分效能・維護性改善
• 不變的
  • 仍是 Windows 專用
  • UI 控制項或設計時部件的相容問題仍在
  • ActiveX / COM / 原生 DLL 問題不消失

另外，WinForms / WPF 有必要確認 BinaryFormatter 的影響 的情況。 特別 clipboard、drag & drop、ResX、設計時的序列化涉及 custom type，把 target 提高到 .NET 9 以後容易表面化。

5.4 ASP.NET Framework 不是「runtime 遷移」而是「app model 遷移」

從 ASP.NET Framework 到 ASP.NET Core 的遷移，Microsoft 指南也明言 non-trivial。 這不僅是 API 名變了，而是 前提的架構不同。

容易出差異的地方如下。

• Hosting model
• Middleware pipeline
• Request processing model
• Session / Cache
• Authentication / Authorization
• Configuration
• Dependency Injection
• Logging / Monitoring

也就是說，ASP.NET Framework 的應用程式該確認的如下。

• 從哪個 route / endpoint 先移
• 能否從 shared library 剝離 System.Web 依賴
• 認證 / session / 例外處理 / 日誌如何對齊
• 是否以不停正式前提分段遷移

特別大的應用程式一開始就以 incremental migration 為前提思考較現實。

5.5 Web Forms 不是「資產遷移」而是從「職責分解」開始

Web Forms 與 ASP.NET Core 不是同個 app model。 所以在估算上 不要以能直接帶走畫面資產為前提 比較安全。

實務上常從以下分解開始。

• 分離畫面邏輯和商務邏輯
• 分解埋在 Page / UserControl / ViewState 的職責
• 把業務邏輯或資料存取逃到 shared library
• UI 用 Razor Pages / MVC / Blazor 等其他模型重組

也就是說 Web Forms 案件 runtime 遷移之前，是否有職責的分解計畫 很重要。

5.6 WCF 用戶端和 WCF 伺服器分開思考

這裡不要混一起比較好。

WCF 用戶端

WCF Client 有 modern .NET 用的 受支援 NuGet 套件。 所以 只是呼叫 WCF 的一側，不如外觀那麼重 的情況有。

WCF 伺服器

另一方面，hosting WCF 服務的一側是另一回事。 Microsoft 指南大致介紹以下 2 個現代化路徑。

• 用 CoreWCF 保持既有用戶端相容的方向
• 靠向 gRPC 等現代 RPC / HTTP 基礎的方向

但 CoreWCF 不是把 WCF 的全部直接帶來，是子集合。 也就是說維持既有用戶端相容適合，但 前提是程式碼變更和測試。

6. 盤查 .NET 不能用 / 直接用會卡的技術

這是著手前絕對該做的地方。 Microsoft 有 在 .NET Framework 能用但 .NET 6+ 不能用的技術 的一覽。

6.1 容易變紅燈的技術

6.2 AppDomain「即使部分 API 留，建立是別的問題」

AppDomain 周邊略複雜。 .NET 雖然部分 API surface 留著，但 建立新 AppDomain 隔離 的用法不受支援。

所以以下用途用 AppDomain 的情況需要重新設計。

• 外掛隔離
• 動態載入的銷毀
• 部分信任程式碼的隔離
• 臨時執行環境的分離

遷移前該看的不是 是否出現 AppDomain 這個詞，而是 為什麼使用 AppDomain。

6.3 Remoting 「比外觀更深」

Remoting 當然，delegate 的 BeginInvoke() / EndInvoke() 呼叫 這類源自 Remoting 的行為也可能進入影響範圍。

所以搜尋時也看以下比較安全。

• System.Runtime.Remoting
• MarshalByRefObject
• RealProxy
• BeginInvoke( / EndInvoke(

6.4 BinaryFormatter 在 target version 突然浮到前面

BinaryFormatter 越舊的程式碼基底越常「無自覺使用」。

• 持久化資料
• 快取
• Session 儲存
• 外掛狀態
• clipboard / drag & drop
• ResX
• WinForms / WPF 設計工具周邊

在 .NET 9 以後，BinaryFormatter 不含在 runtime 的實作中，API 總是擲出 PlatformNotSupportedException。 也就是說這不是「之後想」，是 決定 target version 時要先稽核的論點。

6.5 先 grep 的搜尋詞

著手前對整個解決方案以下列詞搜尋，景色會相當變。

System.Web
HttpContext.Current
System.Runtime.Remoting
MarshalByRefObject
AppDomain
BinaryFormatter
ServiceHost
ChannelFactory
System.EnterpriseServices
Workflow
packages.config
web.config.install.xdt
install.ps1
DllImport
AxInterop
Microsoft.Office.Interop

這些找到 1 個就立即 out 不是這意思。 是 了解哪裡能以標準路線遷移、哪裡需要另外軌道的地圖。

7. 決定允許 Windows 專用前提到哪

遷移中常見的誤解是「遷到 .NET 就變跨平台」。 沒這種魔法。應用程式深度綁 Windows，遷移後也普通是 Windows 專用。

7.1 維持 Windows 專用遷移很現實

Microsoft 有 Windows Compatibility Pack，提供讓登錄、WMI、EventLog、Windows Service、Directory Services 等很多 Windows 系 API 能在 modern .NET 使用的手段。

這很重要。

• 先想遷到 modern .NET
• 但 暫時不走出 Windows
• 所以 暫時允許 Windows API 依賴

這樣的現場相當有效。

也就是說遷移的初期目標不一定是 跨平台化。

7.2 但 Windows 專用 API 也是「之後見效的債」

有 Windows Compatibility Pack 不代表什麼都放心。

• 想裝到 Linux 容器
• 以 Kubernetes 為前提
• 想讓 macOS / Linux 開發者也跑同一個 build
• 將來想在雲中減少 Windows VM

有這類目標就 現在先可視化 Windows API 依賴 比較好。

7.3 System.Drawing.Common 特別容易誤解

System.Drawing.Common 在 .NET 6 以後是 Windows 專用函式庫。 也就是有影像處理或文字繪製的程式碼的話，先決定以下。

• 繼續在 Windows 運營嗎
• 將來也想在 Linux / macOS 動作嗎

前者的話暫時保持也有情況。 後者的話需要從遷移計畫一開始就包含替換為 SkiaSharp 或 ImageSharp 等。

7.4 代表的 Windows 固定氣味

以下參照或 API 出現時，以「至少一開始以 Windows 專用遷移」前提估算比較安全。

• Microsoft.Win32.Registry
• System.Management
• System.Diagnostics.EventLog
• System.ServiceProcess
• System.DirectoryServices
• System.Drawing
• DllImport / P/Invoke
• COM 參照
• AxInterop.*
• Microsoft.Office.Interop.*

8. 共用函式庫切法決定難度

較大的解決方案中，遷移成敗由 shared library 切法決定 不誇張。

8.1 先分類

函式庫大致分 3 類容易整理。

1. 純業務邏輯 / 領域邏輯
2. 略依賴 app model 的中間層
3. 緊密 UI / Web / Windows API 的層

其中最先該遷的是 1。

• 計算
• 規則判定
• DTO / 合約
• 領域服務
• 簡單的資料轉換

這裡能乾淨地拿出來，難度會一口氣下降。

8.2 netstandard2.0 現在也是有效的橋

Microsoft 指南中，需與 .NET Framework 側共存的 shared library，先考慮 .NET Standard 2.0 是基本。

這裡重要的是 2 點。

• .NET Framework 不支援 .NET Standard 2.1
• 想從 old / new 兩邊參照 shared library，2.0 是現實解

8.3 netstandard2.0 化會改變什麼

8.4 相容模式不萬能

.NET Standard 2.0 有參照 .NET Framework 函式庫的相容模式。 但這 不是什麼都透明動作的魔法。

例如以 WPF 這類以 app model 特有 API 為前提的函式庫普通地困難。 也就是說，shared library 也好，只限制於真的能 shared 的職責 很重要。

8.5 ASP.NET 系函式庫能否剝離 System.Web 是勝負

若要分段遷移 ASP.NET Framework，shared library 直接依賴 HttpContext.Current 或 System.Web 會相當痛苦。

此時基本策略如下之一。

• 把 System.Web 依賴推到介面外
• 把來自 HttpContext 的資訊改成以 DTO 接收
• 在遷移過渡期用 adapter
• 還是不行就以 multi-target 分段剝離

8.6 函式庫以 leaf-first 提升

ASP.NET 的 incremental migration 指南明示以 postorder depth-first，也就是 從葉子開始 提升 supporting library。

這不限於 Web，一般的解決方案也相當有效。

• 相依目標先提升，上層的展望好
• 容易局部化相容性問題
• 容易以函式庫單位測試

9. 盤點 NuGet / 外部相依 / 第三方部件

這裡粗略處理，遷移後半會看到最痛的場面。

9.1 相依關係分 4 種容易整理

1. 公開 NuGet 套件
2. 公司內部 private package / internal library
3. 本地 DLL 參照
4. COM / ActiveX / 原生 DLL / SDK

只看 1 不夠。 真正危險的是 3 和 4。

9.2 各相依該確認的

對各相依至少看以下。

• 是否以 modern .NET 為目標
• 是否支援 PackageReference
• SDK 樣式是否沒問題
• 是否有 x86 / x64 / ARM64 的限制
• 是否依賴設計時工具或 Visual Studio 擴充
• 是否以 install script / config transform 為前提
• 支援是否持續

9.3 第三方 UI / 報表 / 設計時部件另外估算

WinForms / WPF / ASP.NET 的遷移，這裡相當有效。

• 格線
• 報表引擎
• PDF 輸出部件
• 圖表部件
• 設計工具整合型的 UI 函式庫
• ActiveX 封裝

這些涉及 不只 runtime 也有設計時支援。 遷移估算只看「能否編譯」會普通地失準。

9.4 原生 DLL 和 bitness 一定要看

在 .NET Framework 時代看似以 AnyCPU 運作，實際上可能依賴以下。

• x86 固定的 COM
• 32bit 專用 ActiveX
• 特定版本的 VC++ Runtime
• 簽章的原生 DLL

這一帶不是 modern .NET 化後突然長出來的問題，是 原本就有的限制表面化。 所以遷移前可視化有價值。

10. 把 EF6、序列化器、資料周邊當別問題處理

runtime 的遷移和資料存取或序列化的重新設計，盡量當別問題處理較順利。

10.1 EF6 → EF Core 不是直接升級

Microsoft 的 EF 指南也說 EF Core 是 EF6 的 total rewrite，沒有 direct upgrade path。

所以使用 EF6 的應用程式以下順序現實。

1. 先遷到 modern .NET
2. 必要的話保持 EF6 讓應用程式運作
3. 之後作為另外的專案遷到 EF Core

這相當重要。 不把 runtime migration 和 ORM migration 一起做，難度就相當下降。

10.2 保留 EF6 會改變什麼

• 好處
  • 可以延後資料存取層的差
  • 能聚焦在 business logic 或 app model 的遷移
  • 不會混入「EF Core 的行為差」
• 注意點
  • 新開發觀點上 EF Core 是本命
  • EF6 Designer / EDMX 使用形態有別限制

10.3 基於 EDMX 的 EF6 看到「設計時」

EF6 的文件寫著 EF Designer 在 .NET / .NET Standard 專案或 SDK 樣式的 .NET Framework 專案上不直接支援。

也就是說基於 EDMX 的應用程式需要分開思考。

• 執行時是否動作
• 是否能用 Designer
• 產生程式碼如何處理

大量使用 EDMX 的話，這個要從一開始放入估算比較安全。

10.4 BinaryFormatter 或自製序列化容易成為「隱藏相依」

序列化器只用程式碼搜尋容易漏看。

• 持久化格式
• 訊息
• 快取
• 舊 WCF / SOAP 合約
• ResX
• 剪貼簿 / drag & drop

這一帶也涉及 資料的相容性。 也就是說不只「能否 build」，還需確認 能否讀舊資料。

11. 把構成、發佈、運營、CI/CD 也包含到遷移對象

遷移的對象不只原始碼。

11.1 設定檔

.NET Framework 側在 app.config / web.config 中可能載了相當多東西。

• connection string
• custom config section
• WCF endpoint 設定
• binding redirect
• diagnostics
• ASP.NET 各種設定
• package install 時 transform 的結果

modern .NET 側的構成持有方式或讀取路徑可能變。 所以「設定檔之後」很危險。

最初要做的是 設定的盤點。

• 什麼在設定檔裡
• 哪些在應用程式啟動時必須
• 哪些是環境差異
• 哪些由 NuGet 或 installer 自動注入的

11.2 發佈方式

以下也該確認。

• 在 IIS 下嗎
• 是 Windows Service 嗎
• 是 Scheduled Task 嗎
• ClickOnce / MSI / 自製 installer 嗎
• 以本地伺服器為前提嗎
• self-contained / framework-dependent 哪個合適

執行本體能遷移，但 發佈和啟動的機制仍是舊前提 最後會卡。

11.3 日誌、監視、運營步驟

運營周邊也容易漏看。

• 以 Windows Event Log 為前提嗎
• 看 Performance Counter 嗎
• 以 WMI 為基礎的監視嗎
• 服務帳戶或權限固定嗎
• 日誌輸出處以本地檔案為前提嗎

遷移後程式碼動了但 運營不轉 普通存在。

11.4 CI/CD 和 build agent

遷移前也確認下列。

• build agent 能否裝必要的 .NET SDK
• 以 nuget.exe / msbuild.exe 為前提的 pipeline 如何處理
• 是否靠向 dotnet CLI 為基礎
• 測試執行、coverage、publish 的 job 如何更新
• 公司內部範本或 reusable pipeline 是否以舊格式為前提

人的本地環境能動但 CI 死 是遷移常見。

12. 現實的遷移進行方式

根據到目前為止的論點，現實的進行方式大致落在下面形式。

12.1 先整頓現行 Framework 側

1. 靠到 .NET Framework 4.7.2 以上、可能就 4.8.1
2. 提升相依關係
3. 重新檢視 packages.config
4. 可能範圍靠到 PackageReference 和 SDK 樣式
5. 確認現行應用程式在這狀態下能好好動作

光做這個，後段的差就會相當減少。

12.2 先救出 shared library

接著把業務邏輯或共通合約靠到 netstandard2.0 或 multi-target。 提升的順序基本是 leaf-first。

12.3 應用程式本體按 app model 變策略

• 類別庫 / 主控台 / 部分服務 相對容易直接進行
• WinForms / WPF 維持 Windows 專用現代化
• ASP.NET MVC / Web API 小就一併，重就分段遷移
• Web Forms 以取代畫面資產為前提，先把 shared logic 逃出
• WCF 伺服器 先決定維持 CoreWCF 或重新設計為 gRPC

12.4 守「不一次做全部」

特別想避免的組合如下。

• runtime 遷移 + ORM 全替換
• runtime 遷移 + 認證基礎變更
• runtime 遷移 + 雲全面遷移
• runtime 遷移 + 監視基礎變更
• runtime 遷移 + UI 框架革新

全部都必要也 不要堆到同個 sprint 大部分較成功。

12.5 取測試和基準線後再動

至少想要以下。

• 單元測試
• 主要業務流程的整合測試
• 代表的畫面 / API 的快照式確認
• 效能基準線
• 主要日誌的確認方法
• 回滾步驟

在不能特定「遷移後壞了什麼」的狀態進行相當危險。

13. 著手前檢核表

以能直接貼到專案管理的形式放。

13.1 方針

• 能用 1 句話說明為何要遷移
• 決定此次著地點是 Windows 專用的 modern .NET 還是 將來的跨平台化
• 決定目標的 .NET 版本
• 決定此次範圍 不包含的（EF Core 化、認證革新、雲全面遷移等）

13.2 現行 .NET Framework 側的整頓

• 靠到 .NET Framework 4.7.2 以上、可能就 4.8.1
• 把相依關係提升到較新
• 盤查 packages.config 的有無
• 確認 PackageReference 化的可行性
• 確認 SDK 樣式化的可行性
• 現行應用程式在該狀態下能 build・啟動・測試

13.3 應用程式類別和技術選定

• 按類別庫 / 桌面 / Web / WCF 等區分難度
• 理解 WinForms / WPF 保持 Windows 專用
• 理解 ASP.NET Framework 是到 ASP.NET Core 的 app model 遷移
• 把 Web Forms 的 UI 層取代納入估算
• WCF 分用戶端和伺服器評估

13.4 不支援技術・要注意 API

• 盤查 AppDomain 依賴
• 盤查 Remoting / MarshalByRefObject / BeginInvoke / EndInvoke
• 盤查 CAS / Security Transparency / COM+ / WF
• 盤查 BinaryFormatter 依賴
• 盤查 System.Web 依賴

13.5 Windows 專用依賴

• 盤查登錄、WMI、EventLog、Windows Service、Directory Services 的使用
• 盤查 System.Drawing.Common 的使用
• 盤查 COM / ActiveX / Office Interop / P/Invoke / 原生 DLL
• 確認 x86 / x64 / ARM64 的限制

13.6 shared library 和資料存取

• 把 shared library 分類為 業務邏輯 / app model 緊密層
• 盤查能 netstandard2.0 化的
• 盤查需要 multi-target 的函式庫
• 判斷能否保留 EF6 只先遷 runtime
• 確認 EDMX / Designer 依賴

13.7 運營和 build

• 盤點設定檔
• 確認發佈方式（IIS / Service / MSI / ClickOnce 等）
• 確認日誌 / 監視 / 權限 / 執行帳戶前提
• 確認 CI/CD 和 build agent 是否需要更新
• 製作回滾步驟

14. 總結

.NET Framework 到 .NET 的遷移重要的是，比起「用哪個命令遷」，是 在著手前看透什麼能直接走、什麼是另一個問題。

特別想掌握的如下。

• 在遷移前整理 .NET Framework 側
• 按應用程式模型分難度
• 先盤查不能用的技術
• 決定允許 Windows 專用前提到哪
• 決定如何切 shared library
• 不要同時堆太多 ORM、認證、雲遷移

遷移，最初 1 週估算的精度會相當變。 反過來說如果那 1 週能整理論點，後半相當能靠到普通的開發。

「先改 net10.0 試試」作為探索不壞。 但作為正式遷移，在那之前有該看的地方。本文整理的正是那個。

15. 參考資料

• 移植程式碼的前提條件
• 從 .NET Framework 到 .NET 的移植概要
• 在 .NET 6 以後不能使用的 .NET Framework 技術
• GitHub Copilot 現代化是什麼
• GitHub Copilot 現代化的安裝
• 官方 .NET 支援政策
• .NET Framework 官方支援政策
• 使用工具把 ASP.NET Framework 遷移到 ASP.NET Core
• 從 ASP.NET Framework 到 ASP.NET Core 的遷移
• Get started with incremental ASP.NET to ASP.NET Core migration
• Use the Windows Compatibility Pack to port code to .NET
• .NET Standard
• Cross-platform targeting for .NET libraries
• 從 packages.config 遷移到 PackageReference
• PackageReference in project files
• BinaryFormatter migration guide
• Windows Forms 用的 BinaryFormatter 遷移指南
• WCF Client Support Policy
• CoreWCF Support Policy
• Why migrate WCF to ASP.NET Core gRPC
• Port from EF6 to EF Core
• EF6 的新功能