既然 WPF 和 WinForm 只能在 Windows 運行，為什麼要移植到 .NET Core ？
.netcore聲稱自己是跨平台的.net實現，而在其上實現的wpf和winform又不能跨平台，感覺很矛盾。
你對跨平台框架這件事情理解有偏差。
跨平台框架說的是，框架可以跨平台，而不是，必須跨平台的東西才能放進框架，也不是框架里的任何一部分都必須跨平台。Unity是跨平台的吧，但你用它來做一個Windows only的app，有人攔得住你？
其次，Xamarin很久以前曾經表態過，WPF是可以跨平台的，只是錢的問題。有人願意投入就能做成跨平台，不是技術問題。
再者，如果所有東西都遷移到.net core，就可以脫離老的.net，只需要維護一套，成本就能降低。why not。
因為這個統一.NET平台的第一步。
目前你寫一個嚴肅的C#程序，需要適配 .NET Framework、.NET Core、Mono、.NET Native等多個平台。最初這個工作只需要修改一些csproj文件就可以了，但隨著我們給CoreCLR的VM和JIT加入更多功能，適配多個平台這個工作已經大面積泄漏到了上層語言中（比如在C#中寫#if條件編譯）。要把這些新功能移植到 .NET Framework的VM/JIT里甚至比在.NET Core 中做新功能時還要麻煩（比如照顧JIT32）。所以微軟在2018年的時候就決定 .NET Framework 不再跟隨支持新的 .NET Standrad。
所以這是對用戶和 .NET開發人員有百利而無一害的事情，何樂而不為呢。
clang++也是跨平台的，但是也擋不住大家寫出了一堆linux only的代碼。道理是一樣的。
WPF也不是不能做成跨平台，但是首先你要有大量的Linux開發GUI的需求。Linux能寫GUI也是好多年了，但是大家並不喜歡，那做成跨平台意義何在？當然我覺得WPF跨平台也是遲早的事情，因為總有一天要上mAC的。
主要是能讓wpf、winform享受到.NET Core的性能優勢和新特性，現在很多新的類庫都用.NET Core寫了，.NET Core3.0有一部分新特性是用到.NET Standard 2.1，framework是不能引用了，所以這時候讓他們支持.NET Core，是非常受歡迎的～
另外，社區還有一些.NET core實現的跨平台Xaml框架，可以了解一下～
Windows平台上的應用開發，我們通常會選擇以下三個技術：
- Windows Forms
- Windows Presentation Foundation
- Universal Windows Platform (UWP)
但事實上, 你真正想瞄準的是 Windows。Windows是平台。 這些選項只是我們針對 Windows 開發應用時所擁有的不同 UI 框架選項。更重要的是, 當你優化你的應用針對 Windows 10 時, 你會得到更多的創新、Api 和 windows 10 操作系統為您提供的好處。
把 Windows 看作是一個平台。
UI 框架只是一種偏好而且, 這三個UI 框架現在都是開源的：
- Windows Presentation Foundation: https://github.com/dotnet/wpf
- Windows Forms: https://github.com/dotnet/winforms
- Windows 10 XAML: https://github.com/Microsoft/microsoft-ui-xaml
WPF 和 Windows Forms 開源都是基於.NET Core 3.0, 你肯定有疑問為什麼是 .NET Core 3. 給我個理由?
.NET Framework 4.8 已經發布，.NET 4.8 已經幫助我們解決了很多問題， WPF和Windows Forms的高DPI更好的至此，Windows 10 中最新的瀏覽器和媒體播放器的新控制項，並支持最新的標準。.NET Core 3 是 .NET Core 的下一主要版本。 這個即將發行的版本的主要特點是支持 Windows 桌面應用，包括 Windows 窗體和 WPF 應用。 你將能夠在 .NET Core 3 上運行新的和現有的 Windows 桌面應用並體驗 .NET Core 具有的所有優勢。 託管在 XAML 島中的 UWP 控制項也可在面向 .NET Core 3 的 Windows 窗體和 WPF 應用中使用。
.NET Core 的性能更好，速度更快，.NET Core的並行安裝的特性可以幫助你在發布應用程序中獲取顯而易見的方便，更好的打包方案MSIX， 開源，支持.NET Standard 2.1, 支持C# 8.0等還有很多新特性。
使用.NET Core 3 升級Windows 桌面應用開發的好處還有很多，下面簡要的列幾條：
?現代運行時、BCL 和語言功能
?更容易訪問平台和設備的API
?現代化 且可訪問的的UI和輸入
?針對 DevOps 進行無縫的應用程序部署、更新和優化
?開發人員更好進行敏捷創新
.NET Core 3.0 將在下個月發布RC， 9月份正式發布，將在11月份發布長期支持版本3.1 ，2020年 11月發布.NET 5 ,其實就是.NET Core 4.0 ,為了避免和.NET 4的混淆，以及統一.NET品牌的考慮統一叫做.NET 5,往後每年發布一個主要版本, 發布的偶數版本是LTS。
.Net真正意義上不能跨平台的也就是用到PInvoke Windows下專用的DLL的那一套東西吧，其他只要肯把底層原來對Win32依賴的那一套輪子敲出來，理論上也是可以跑到別的平台上的。
微軟要移植，其實只是看他們想不想，肯不肯出成本。別說WinForm跨平台了，微軟以後搞個Win32 on Linux都是可能的，只不過會是個巨大的工程。
記得Mac OS還不是X的時候，微軟已經搞了個Visual C++ for Mac跨平台版本（應該是97年左右，是Visual C++ 4.2的一個特殊版本）。裡面把一部分Win32 API和整個MFC都移植到那個時候的Mac OS上了，記得Mac版本的Word 6.0、Excel 5.0都是用這玩意開發出來的；當然IDE沒移植，需要在Win下寫代碼，然後用串口連接到Mac真機調試。只不過，在Mac用戶和開發者的強烈排斥下（它太微軟了），這個平台沒有能走出去多遠。
WinWorld: Visual C++ 4.x?winworldpc.com.netcore 是一個汽車製造平台, 可以不同大小的汽車.
WPF ,winform 其中的一款車
微軟跨平台是為了多賺錢，而不是學雷鋒
微軟開始跨平台是商業策略，為了搶佔伺服器市場獲得盈利。通過Azure，即使Linux伺服器也可以賺到錢。而且這部分收入已經向每年100億美元邁進，並且幾年內就會翻番。
微軟最強大的桌面開發工具只支持Windows，也是商業策略。微軟的實力做跨平台很容易，比如VSCode，但為了防止Windows的市場份額丟失而人為限制。微軟大部分收入依然都來自於Windows和辦公軟體，有著數萬億美元的市場。
而桌面跨平台最成功的Qt，估值也只有幾億美元。損害數萬億的市場，來獲取幾億的市場，顯然得不償失。在收益大於損失之前，估計WinForm和WPF並不會真正跨平台。而UWP與微軟設備綁定，跨平台就更困難了。
.NET Core 5 將要統一版本，取代Frameworks
第一次看到移植的新聞，確實感覺是多此一舉。
後來有消息，5.0將完全統一合併。原來如此。
另一個猜想，如果未來微軟壟斷了Windows和Linux開發……
會不會被拆分？比如反壟斷什麼的。或者歐洲開出千億罰單之類。
有人聽說過MONO這東西嗎？如果沒聽說過MONO，那你聽說過Xamarin公司嗎？MONO就是Xamarin公司旗下的東西，而Xamarin已經被微軟收購了。
而UNITY3D中已經在使用MONO的技術了，微軟也一直和UNITY公司保持一種曖昧的關係，包括WP7/WP8中也在使用UNITY3D的引擎。
這位說微軟很尷尬的兄弟，先不說微軟和UNITY的老鐵關係。要麼先去了解下Mono AOT和.NET 5？
Introducing .NET 5 | .NET Blog?devblogs.microsoft.com
微軟官宣.NET 5要通過Mono AOT實現跨平台了，其中BLAZOR將是第一個遷移到Mono AOT上的，而後面WPF、WINFORM也會陸續遷移過去。
BLAZOR也是個好東西，以前前端都是用JAVASCRIPT來開發，後來NODEJS出現了，後端也可以使用JAVASCRIPT來開發了。現在BLAZOR是倒過來了，以前後端可以使用C#來開發（http://ASP.NET），現在前端也可以使用C#來開發了（BLAZOR）。結合起來，其實和ELECTRON那是幾乎一樣的道理。
JAVA有一個承諾，跨平台的承諾不是可以隨便break的
.NET 5也有一個承諾，跨平台的承諾也不是可以隨便break的
興許，就像知乎人均預測那樣，微軟就是一個不到1年時間就會倒閉的公司吧，哈哈哈……
我隨便感慨下，今天最火的前端框架之一，vue用的MVVM模式，再學學10年前WPF，貌似一樣的，雙向數據綁定，事件驅動路由，UI顯示方式為數據決定顯示而不是pull過來。其中wpf比vue的組件間通信方式更極端些，幾乎是完全數據驅動。當然，也可以用c#在後台自定義各種實現。但wpf不受解析度限制，UI可跨各種解析度。
站在微軟的角度，.Net Framework的包袱是真的不想繼續背了，馬上的.Net5即將統一Framework和Core了，大家都是一套CLR和BCL多省心。就像你自己開發個WPF項目，需要不同語言的版本，你願意重新寫一套後端代碼么。。。
目前在Linux上尚未實現winform和WPF的UI框架，不是做不到，只是任務還沒排到，從2016年發布.NET Core開始，整個.NET部分確實做了很多開發適配工作，到如今2020年9月份，已經持續更新了N多個版本，.NET5也馬上上線了，工作量太大，理解下。之前在Scott(微軟.NET負責人)的博客裡面說過這事兒，將來會推出UI解決方案的，所以，讓我們騎驢看唱本~
因為老的.net framework要被拋棄了，全部整合到.net core下，桌面端對微軟來說很重要，那麼為什麼.net core里可以存在windows only的官方組件呢，這當然還是微軟不願意做唄。
至於跨平台有沒有可能，還不好說，各平台的xaml還比較混亂，不好好統一冒然搞跨平台事情也不會好到哪裡去，這個東西現在規划起來頭疼，也是微軟一開始就沒做好的後果。
其實微軟換個思路，萬一windows暫時不行了，還有人用.net跨平台開發給他苦苦撐著，等待windows重整雄風時才有應用，這個思路就比較正確了，在這種思路下會更好的做跨平台UI， 也就是因為沒這個思路，WP掛了，win8差點完蛋，到win10才喘回來，而UWP也還是不火。
因為windows不行而.net也不行時，會雙雙拋棄，而windows不行時.net還是可以時候，起碼這幫人還能給windows開發東西，再想想wintel聯盟在手機端為什麼掛掉的，雙雙掛掉的事情太正常了，不能讓有點希望的東西跟著阿斗掛掉啊，要儘快找到自己的出路，回頭才有救大哥的可能，.net就是這樣，自己要找到出路，讓更多的人願意用，回頭才有拯救大哥windows的機會，幸好mono幫了.net一把，讓微軟覺得開源和跨平台是有用的。
Win系技術 不過是一個個介面集合。WPF 就是一套介面的集合，可以有多個實現，各個實現都實現了 WPF這套介面，讓你作為 API Caller 覺得似乎沒差。
.NET 官方 package 參考表
WPF 有 2 個實現，一個是自 .NET Framework 3.0 就開始演進的實現，另一個是在 .NET Core 出現之後 專門為它做的實現，並包含於做成 nuget 包 ( *.nupkg) 即 Microsoft.NET.Sdk.WindowsDesktop 包
.NET Core 作為一個開源技術棧，必然有基於包管理的生態 ( 參考 python 的 pip, ruby 的 gem, node.js 的 npm )，以統一的方式管理第三方包 ( 即標準庫之外的東西，通通用包來 import ) 並處理包依賴關係 ( A包 B包 同時依賴C包 的情況下自動載入該載入的包，並生成類似 Gemfile.lock 的包依賴關係說明，記錄本項目中所依賴的 nuget 包。bundle install 命令對應了 dotnet restore )。WPF 團隊一定會出一個版本 ( implementation ) 去專門支持 .NET Core 的，而且是以 .NET Core 喜歡的形式 ( nuget 包 )。 —— 跨平台是不可能跨了，歷史包袱太重 Win系技術的常識，頂多給弄一個復刻版，re-implementation 。
.NET 技術從舊式邁向新式 ( 標準庫 + package ) 。但是 顯然 .NET Framework 的歷史包袱太沉重了，所以 .NET Core 出爐了，順便搞了跨平台 ( 各式各樣的 Win系技術的 re-implementation )。
各個技術在 .NET Framework 上，有一份 implementation ，在 .NET Core 上，有第二份 implementation 。
你可以說，自 .NET Framework 3.0 引入的 WPF 和 .NET Core 的 nuget 化的 WPF ( 包含於 Microsoft.NET.Sdk.WindowsDesktop package ) 是不一樣的，這是2個 implementation：相同點是 API 保持了不變 ( 所以也仍然叫做 WPF 技術 )；不同點是 前者經過了時間的考驗，後者尚未經過時間的考驗 ( 甚至包名還在改 ... 從 Microsoft.NET.Sdk.Wpf 到 Microsoft.NET.Sdk.WindowsDesktop ) 也即 highly experimental 。
dotnet/wpf
跨平台是結果，不是目的。微軟家只是想把各個技術，從 .NET Standard 到 WPF ，都給整出新的 implementation 而已，而且這些技術的新版 implementation 能相互咬合，就完事了。—— 雖說宣傳的是 「一個跨平台的新主張 ( 在 linux 上也能跑 http://ASP.NET Core 了喲 )」，但最後 興許還能幫助 Windows Server 的銷售 ... 最後，鑒於 C# 幹掉過 Delphi 的故事，我不由得為 Java 擔心。
C# 已經到 8.0 版本了，微軟家若真想跨平台早就跨了。如果說目的，跨平台不是目的，滅平台才是目的，幫助賣 Windows Server 伺服器 ( 並降低遷移門檻 ) 才是目的，推 Azure 才是目的。
因為微軟懶得維護.NET Framework那一堆歷史包袱了，改點兒啥都幾萬的單元測試（我猜的）。
新的功能和特性都會在.NET Core上實現，而.NET Core竟然開發不了Windows GUI應用，這就很尷尬了……
當然了，其實工作量也沒多大，就是重新適配一下，對接一下dotnet core的BCL，沒打算在Linux和Mac上跑……
移植這個說法很可疑，準確的說應該是適配……
有什麼矛盾的，WPF 和 WinForm ，windows 平台的代碼都開源給你了，有需要自己實現唄。
難道送佛非要送到西么。
關於跨平台， 叛逆者說得在理。
平台跨平台，並不代表平台上的 不可以開發/發布 不跨平台的 應用和庫。
題主你就跟你老婆或女票說「既然家裡的化妝品只有你在用、新衣服只有你在穿，為什麼要花我的錢買？我們當初約定我們賺的錢都是大家的，而你買的化妝品、新衣服又只有你在用，感覺很矛盾。」
然後，你就知道為什麼了（逃
Avalon不就是跨平台的WPF嗎
要明白微軟動機是什麼，微軟不是活雷鋒。之所以推出.net core,支持Linux，是為了擴大微軟在伺服器端的佔有率，如果wpf也能在Linux運行，大量的windows桌面軟體就可能會有Linux版，然後呢，Windows在桌面端的壟斷性降低
只是讓wpf使用core的核心，提升某些計算能力吧。
還沒在wpf上用過，自己瞎琢磨：
一是如樓上所說提升計算能力，二是以後發展方向是core，傳統的.net只是跟著走直至走失，三是能編寫遊走於伺服器和客戶端的dll，充分發揮客戶端的處理能力。最後，wpf必然會誇平台的，silverlight已經為它實踐過了
推薦閱讀：
※WPF 的設計思想先進都體現在哪些方面？
※要開發一個倉庫管理軟體，應該選擇c#（winform/wpf）還是c++(qt)?
※wpf求教導，用數據綁定，slider 和 3個radiobutton 相互聯動？
TAG:MicrosoftWindows | NET | WindowsPresentationFoundationWPF | NETCore | Winform |