移植 .NET Core 計畫，整合各平台變得更簡單了！
【2016/6/27 號外】.NET Core 1.0 ! 正式釋出 --> 詳情請見 連結
在前篇文章中我提到了如何移植 .NET Core，並邀請使用者們不吝嗇的回報您的使用經驗和改進意見。
這項措施帶動起了非常多使用者之間的討論。
根據這些討論的重點和我們與第一與第三方夥伴合作的經驗，我們決定把核心 API 跟其他 .NET 平台，主要是 .NET Framework 和 Mono/Xamarin，做一次整合，藉此來大幅簡化移植 .NET Core 的功夫。
在此篇文章中，我會介紹我們的計畫、我們將會如何達成這個目標、預計的上市時間，以及這對現在 .NET Core 使用者的意義。
回顧 .NET Core
.NET Core 平台 起始於微軟對於開發者們想要研發一個現代化、模組化、app-local、並且能夠跨平台的 .Net stack 所推出的產品。這項產品背後的商業目標是希望可以提供一個整合的 stack 給全新的應用程式(例如：觸控型 UWP 程式) 或者現代跨平台程式(例如：ASP.NET Core 網站與服務)。
在我們即將推出的 .NET Core 1.0 中，我們成功的開發了一個強大的跨平台開發 stack。.NET Core 1.0 開創了把 .NET 推行到所有平台的先河。
雖然 .NET Core 在我們所制定的情境中運行良好，但不能否認的是它相較於其他市場上的 .NET 平台來說，可兼容的程式較少。相較於 .NET framework 時此情況尤其明顯。一部分是因為不是所有東西都是以跨平台做為目標的情況下開發的，另一部分也是因為我們把一些我們認為不必要功能給刪除了。
種種原因之下，我們了解到如果想要學習並使用 .NET Core，現役的 .NET 開發者必須花費很長一段時間來移植它。
當然，直接重新編一個新的 API 給新的客戶也是一個不錯的方案，但是這種作法彷彿變相的懲罰了長年以來一直使用微軟 API 與技術的忠實客戶。我們是想要把 .NET 平台變得更加強大，並推廣給更多的開發者，但是我們並不能漠視現有使用者的權益。
Xamarin 在這一點上就做得非常好。他們使 .NET 開發者們輕鬆地在 iOS 和 Android 手機上開發行動程式。讓我們來看看 iOS，iOS 其實跟 UWP 有許多的相似之處，例如對終端使用者經驗的高度重視和對靜態編譯的要求。Xamarin 跟 .NET Core 不同的地方在於， Xamarin 並沒有重新構想 .NET Stack。 Xamarin 把 Mono 整套搬過來，刪去了應用程式模型元件 (Windows.Forms, ASP.NET)，加入了 iOS 的元件，再改動了一些細節使其適用為內嵌使用。由於 Mono 和 .NET framework本質上非常相似，經過這種處理方式之後的 API 是非常容易被現役 .NET 使用者學習與接受的，並且使移植現有的程式碼到 Xamarin更為輕鬆。
當初在構想 .NET 的時候，我們最重要的核心理念就是希望可以使開發者更有生產力以及協助他們撰寫更嚴謹的程式碼。我們設計 .NET 能在更豐富的領域和情境中幫助開發者，從桌面和網站應用程式，到微服務、行動應用程式、甚至遊戲的研發。
為了實現我們的核心理念，開發出一個統一的核心 API，並使其可以在任何條件下使用是必要的。一個統一的核心 API 可以使開發者們簡單的實現程式碼共享橫跨不同的工作量，使每一位開發者的專長可以得到最好的發揮 ──寫出最好的服務與使用者體驗。
.NET Core 的展望
在 Build 2016, Scott Hunter 即展示了下列投影片:
我們想要展現給各位的理念是：
不論您是想要寫桌面應用、行動 App、網站，又或者是微型服務，您都可以使用 .NET 來幫您達成您的目標。也因為我們提供統一的 BCL，程式碼共享將會是一件非常簡單的事情。作為一個開發人員，您可以專注在功能與技術對應至您選擇的使用者體驗與平台。
我們想要這樣實現這些理念：我們將會為以核心基礎類別庫 Base Class Libraries （BCL）為目標的應用程式提供原始碼和二進位碼相容性（binary compatibility）, 並保證在所有平台上運作方式的一致性。基礎類別庫（BCL）就是那些存在在 mscorlib、System、System.Core、System.Data、System.Xml，而這並不限定特定的應用程式模型和作業系統實作。
不論你將目標放在 .NET Core 1.0 的 surface（以 System.Runtime 為基礎的 surface），還是在即將釋出有擴充 API （以 mscorlib 為基礎的 surface）的 .NET Core 版本，你目前的程式碼都將可以繼續使用。
我們承諾簡化將現有程式碼移植，也將同樣保證在函式庫與 NuGet 套裝軟體上。當然包含可攜式類別函示庫 （portable class libraries）無論他們使用的是 mscorlib 或是 System.Runtime。
這裡有幾個有關這次新增的例子可以讓你使用 .NET Core 起來更為順手：
- Reflection 將會變得跟 .NET Framework 一樣，不需要 GetTypeInfo() ，而舊的 .GetType() 回來了。
- 型別將不再會缺少因為清理原因而已經刪除的成員（Clone()、Close() vs Dispose() ，舊的 APM APIs）
- 二元序列化（BinaryFormatter）將又可以使用
可以到我們 corefx GitHub 的套件庫查看更完整的計畫新增名單。
對 .NET Core 的意義
從我們跟社群的對話當中我們瞭解到他們的疑慮，使用者們擔心這些新增的 API 功能會使得 .NET Core 體驗大打折扣，這完全是個誤解。我們對 .NET Core 絕大多數的投入, 不論是能以 app local 的方式推出，還是 XCOPY deployment, 又或者是我們的 AOT 編譯器工具鏈，其開源與跨平台的理念是不變的。這同樣適用於所有額外的功能和我們對效能的改進，例如新的網路組件 - Kestrel。
一開始當我們在設計 .NET Core 時，就強調模組化以及付費使用的概念，這表示您只需要消耗最終使用之功能的磁碟空間。我們相信我們仍然可以實現這些目標而不會對相容性問題造成太大的影響。
最初，我們仰賴將功能分割在微小的函式庫中來最小化程式的磁碟利用率，而我們也知道用戶喜歡這一點。現在，我們將提供一個比其他手動程序還要更為精確、更好的儲存空間的鏈接工具。這是類似於 Xamarin 開發者現已使用的方式。
時程與流程
在我們推出 .NET Core 1.0 RTM 後，我們將開始著手擴充 .NET Core 的 API 介面。如此，持續追蹤 .NET Core 的你們即可部署至生產環境。
在未來幾週，您可以在我們的 corefx GitHub 看到更多詳細資訊與計畫。首先我們會做的就是釋出一系列 API references，列出我們將會推出的 API，那麼當您在移植程式碼時，您就可以有所依循來決定是否要跳轉到 . NET Core 1.0 或是等待即將推出的 APIs。同時，我們也會宣布哪些 API 我們不打算推出，我們希望能為我們的用戶提供一個看板，以查詢專案的狀態與目標。
這次將會是對我們為 .NET Core 1.0 做準備所遵循的流程的一大改善，前次發表因為內部流程分享不夠公開而造成的不圓滿，將在這次修正。
最後，我們計畫在 NuGet 上推出更多的 . NET Core API 更新。這些更新會是漸進式的，亦即是我們將會擴充現有的 API 功能，並同步推出更多的 API。這樣一來，使用者們可以得到好處，不用等到 API 完全更新結束才開始使用。這同時也可以讓我們把各位對於運作方式的意見與回饋加入我們的更新中。
在接下來的幾週內，我們將會在 corefx 套件庫公佈更多的資訊。你可以在這個部落格討論相關狀態以及所有的重大決策。
本文翻譯自 Making it easier to port to .NET Core
若對以上技術及產品有任何問題，很樂意為您服務! 請洽：台灣微軟開發工具服務窗口 – MSDNTW@microsoft.com / 02-3725-3888 #4922
Comments
- Anonymous
July 05, 2016
我有興趣了解請與我聯絡 0937298290- Anonymous
September 08, 2016
陳先生您好謝謝您對於此篇文章的介紹有興趣麻煩您寄信到 MSDNTW@microsoft.com我們將會有專人與您聯絡謝謝!
- Anonymous