原文: 分析現有 WPF / Windows Forms 程式能否順利遷移到 .NET Core 3.0（使用 .NET Core 3.0 Desktop API Analyzer ）
版權聲明：本作品采用知識共享署名-非商業性使用-相同方式共享 4.0 國際許可協定進行許可。歡迎轉載、使用、重新釋出，但務必保留文章署名呂毅（包含連結：http://blog.csdn.net/wpwalter/），不得用于商業目的，基于本文修改後的作品務必以相同的許可釋出。如有任何疑問，請與我聯系（[email protected]）。 https://blog.csdn.net/WPwalter/article/details/82859449
今年五月的 Build 大會上，微軟說 .NET Core 3.0 将帶來 WPF / Windows Forms 這些桌面應用的支援。當然，是通過 Windows 相容包（Windows Compatibility Pack）實作的。為了提前檢查你的程式是否能在未來跑在 .NET Core 3.0 上，微軟在 2018年8月8日 推出了 .NET Core 3.0 Desktop API Analyzer，幫助你提前檢查你的程式能有多容易遷移到 .NET Core 3.0
本文将介紹其使用方法，并介紹 API 的逐漸遷移方法。
.NET Core 3.0 Desktop API Analyzer
你可以前往 GitHub 檢視 .NET Core 3.0 Desktop API Analyzer 項目：
去 release 标簽下即可下載下傳。當然，目前僅釋出一個版本，你也可以點選以下連結直接下載下傳：
下載下傳完後解壓到任意目錄即可運作。
分析一個 WPF 程式
第一個想到的，是分析目前已在商店釋出的基于 .NET Framework 4.7 的 WPF 程式
辨別符命名工具 - Whitman。
▲ 分析 WPF 程式
其實這個目錄下隻有一點點程式集，是以分析起來很快的。
▲ Whitman 的目錄結構
選好後，點選 Analyze，在 Analyzing… 提示等待之後，即可在它指定的臨時目錄中找到分析結果檔案：
Report saved in:
C:\Users\walterlv\AppData\Local\Temp\PortabilityReport.xlsx
竟然是一個 Excel 表格！
▲ Excel 表格表示的結果
可以看到，我的 Whitman 對 .NET Core 3.0 的 API 是 100% 相容的。将來遷移的時候可以不需要修改代碼。
分析更複雜的程式
我試着分析一個更龐大的 WPF 軟體目錄後，發現還是有一些 API 是不相容的。
▲ 有一些 API 不相容
▲ 有一些程式集相容性很低
這份 Excel 表格中還包含了具體哪些 API 是不相容的，并為部分使用提供了建議：
▲ 檢視不相容的 API
是以，我們隻需要查找對對應 API（第一列）的使用，然後通過其他技術手段将其替換成别的方法來寫即可解決這樣的相容性問題。
着手解決相容性問題
比如我們拿出其中一行：
| Target type | Target member | Header for assembly name entries | .NET Core | Recommended changes |
|---|---|---|---|---|
| T:System.Runtime.Remoting.Messaging.MethodCallMessageWrapper | Walterlv.Placeholder | Not supported | Remove usage. |
我們通過在 Walterlv.Placeholder（這隻是個占位程式集，實際名稱已隐去）中全解決方案中搜尋
MethodCallMessageWrapper
可以找到此 API 的所有使用。
public override IMessage Invoke(IMessage msg)
{
var caller = new MethodCallMessageWrapper((IMethodCallMessage) msg);
// 省略其他代碼。
}
此方法在此處上下文的目的是實作 AOP 代理，即為了實作切面程式設計，允許在實體類的每個方法執行之前注入一些代碼。
既然此處基于 .NET Framework
MethodCallMessageWrapper
的 AOP 已不可用，那麼我們需要尋找到 .NET Core 中 AOP 的替代品。例如 .NET Core 官方推薦的是：
于是，我們幾乎需要改造此類型，使其對 .NET Framework 中
MethodCallMessageWrapper
的使用替換成對
AspectCore-Framework
的依賴。
這是一項繁重的工作，不過還是要做的。遷移到 .NET Core 有很多好處，不是嗎？
一些錯誤
額外的，在其他一些程式的分析中，我遇到了一些錯誤。通過混淆的比較，我認為此錯誤可能源于程式集的混淆：
Unable to analyze.
Details:
Detecting assembly references [Failed]
Cannot locate assembly information for System.Object. Microsoft assemblies found are:
Cannot locate assembly information for System.Object. Microsoft assemblies found are:
Cannot locate assembly information for System.Object. Microsoft assemblies found are:
Cannot locate assembly information for System.Object. Microsoft assemblies found are:
Cannot locate assembly information for System.Object. Microsoft assemblies found are:
Cannot locate assembly information for System.Object. Microsoft assemblies found are:
Cannot locate assembly information for System.Object. Microsoft assemblies found are:
Cannot locate assembly information for System.Object. Microsoft assemblies found are:
如果你想了解更多混淆相關的資料，可以閱讀我的另一篇部落格：
.NET 中各種混淆（Obfuscation）的含義、原理、實際效果和不同級别的差異（使用 SmartAssembly）未來的遷移
.NET Core 并不會原生提供 WPF / Windows Forms 這些桌面應用的支援，而是通過 Windows 相容包（Windows Compatibility Pack）實作。你可以閱讀微軟官方部落格了解：
Announcing the Windows Compatibility Pack for .NET Core - .NET Blog遷移到 .NET Core 并不會為這些程式帶來跨平台特性，隻是能夠充分利用到 .NET Core 帶來的諸多好處而已。比如更高的性能，更友善的部署，及時的更新。當然還有 MIT 開源，我們能夠和社群一起修複 Bug。