概述

下面是 ASP.NET Core的時間表和路線圖. 注意日期和特性都可能更改.

作為.NET Core這麼大的一個專案,很難準確預測每一個計劃的是否有變動.

即便如此，我們還是計劃公開和透明的實施，以便我們的使用者可以有正確的期望值，

併為我們的使用者自己在技術實施時有更好的打算和安排

釋出時間表

Release 版本特性

1.1

• URL 重寫中介軟體
• Response 快取中介軟體
• 第三方DI支援的實現
• WebListener 伺服器(Windows only)
• MVC filters中介軟體
• Tag Helpers
• View 預編譯
• 基於Cookie的TempData provider
改進Azure
• App Service 啟動時間改進
• App Service 日誌provider
• Azure 金鑰儲存庫 provider

1.2

• WebSockets
• SignalR 兄弟我等了兩年了!(Linux不支援Websocket模式)
• Razor Pages (Views 不含 MVC controllers)
• Web API 安全

廢除技術概述

雖然有一部分現有的.NET應用程式，尤其是基於ASP.NET MVC的應用程式將能夠比較簡單地遷移至.NET Core，但另一部分.NET應用在遷移過程中可能會遇到某些問題。有一些問題是顯而易見的，例如從WinForms或WPF應用遷移至 Universal Windows Applications（UWP），而另一類些問題則更加微妙，這關係到.NET Framework核心功能中更底層的實現。

反射

反射API在.NET Core中產生了很大的變化。正如在WinRT中的應用方式一樣，反射功能被分成一種輕量級的版本以及一種開銷更大的版本。來自微軟的Immo Landwerth寫道：

在推出.NET Native時，我們利用了一種技術，它允許我們將應用與框架和第三方依賴進行靜態連結。要使這種連結功能可行，它必須能夠找出在你的應用沒有使用的那部 分框架功能。對於其他技術，例如C++來說，這一過程並不複雜，因為這種系統並不具備反射這樣的動態能力。當然，在.NET Native中仍然支援反射，但我們希望讓這個平臺儘可能地降低開銷，也就是說不必為你所不需要的特性增加開銷。這一點對於反射來說尤其明顯，因為它對於 執行時以及編譯器能夠基於靜態資訊進行哪些操作施加了極大的限制。

因此，在理想的情況下，反射應當作為.NET Core中一個可選的元件，你可以選擇在自己的應用中完全放棄使用它。麻煩在於，System.Object在進行Object.GetType()操作 時將對反射產生依賴。為了打破這種依賴，我們決定讓System.Type不再展現整個反射型別資訊，而僅僅展示型別的名稱。這也意味著在.NET Core中的System.Type不再包括GetMembers()等API，但仍然會暴露Name等API。

通過一個名為GetTypeInfo的擴充套件方法，可以得到在一般情況下能夠從Type物件中獲取的資訊。TypeInfo類所包含的資訊沒有原來那麼豐富，但微軟最近決定在.NET Core中重新引入一部分反射API，這部分變更是超出原先計劃之外的。

為了使程式碼更容易進行移植，.NET 4.5及之後的版本提供了對TypeInfo的某種支援，它與在.NET Core中使用的版本相類似。

App Domain

App Domain在CoreCLR中得以實現，但沒有在.NET Native中實現。由於對App Domain的實現需要大量的執行時特性支援，因此目前還沒有任何對它的支援計劃。“對於程式碼的隔離，我們建議通過程序或容器實現。而對於程式集的動態加 載，我們建議使用新的AssemblyLoadContext類。”

Remoting

現如今，已經很少有開發者還能夠記起Remoting庫的存在，更不要說如何使用它了。即使還有人在使用，他們也一直在抱怨它的效能、高複雜性以及總體表現的脆弱性。

如今，多個.NET應用在同一臺機器上的通訊基本都被WCF所取代，後者能夠帶來更好的效能，可用於管道或記憶體對映檔案。對於跨機器的通訊，微軟推薦“使用一種低開銷的純文字協議，例如HTTP”。因此，微軟並沒有在.NET Core中支援Remoting的計劃。

序列化

通過這十年來的經驗，我們終於瞭解到序列化是一項非常複雜的任務，支援序列化的型別在相容性方面要面對沉重的負擔。因此，我們已經決定讓序列化 成為一種協議，它將在可用的公開API的基礎上實現。然而，二進位制序列化的實現需要對型別本身的深入瞭解，因為這種方式可以對整個物件圖進行序列化，甚至 包括私有的狀態資訊。

沙箱

從理論上說，沙箱是一種優秀的思想，它允許部分信任程式碼以安全的方式執行。但在實踐中，要想正確地應用它非常困難，哪怕是一點點微小的錯誤，也會導 致安全性方面的漏洞。Immo Landwerth還表示，它“使實現變得更加困難，並且經常會給未使用沙箱的應用的效能帶來負面影響。”

推薦的替代方案是使用獨立的程序，通過一個具有有限許可權的使用者帳號執行這些程序。通過這種方式，執行時不必重複進行一些開銷較大的許可權檢查工作，因為作業系統已經為你完成了這方面的任務。

其他元件

微軟正考慮將下表中列舉的元件進行開源，並移植到.NET Core。

• System.Data。雖然它的基礎層功能，即提供者模型與SQL client 已經成為了.NET Core的一部分，但某些特性目前仍不可用，例如對於schema、DataTable和DataSet的支援。

• System.DirectoryServices。.NET Core目前並不支援通過該元件與LDAP或活動目錄進行通訊。

• System.Drawing。雖然從嚴格意義上來說，它應該屬於一種客戶端API，但還是有大量開發者在服務端通過繪圖API實現縮圖或水印的生成。我們目前還不支援在.NET Core中使用這些API。

• System.Transactions。雖然ADO.NET支援事務，但並不包括對於分散式事務的支援，後者包括氛圍事務（ambient transaction）及資源徵集（enlistment）的概念。

• System.Xml.Xsl與System.Xml.Schema。.NET Core支援XmlDocument以及由Linq引入的XDocument，包括XPath在內。不過，目前還不支援XSD（XmlSchema）及 XSLT（XslTransform）。

• System.Net.Mail。目前還不支援在.NET Core中通過這些API實現電子郵件的傳送。

• System.IO.Ports。.NET Core目前還不支援與序列化埠的通訊。

• System.Workflow。Windows Workflow Foundation（WF）目前在.NET Core中尚不可用。

• System.Xaml。在開發UWP應用時，開發者將使用WinRT XAML API。因此，.NET Core目前並不支援託管XAML框架，後者包括解析XAML、並例項化描述物件圖的功能。

你是否有興趣幫助我們移植某個元件？.NET Framework實現的部分原始碼已經通過MIT許可進行了開源，作為Reference Source的一部分。我們正在設法讓社群能夠對我們的移植工作提供支援。如果你願意參與這一專案，請傳送郵件至[email protected]。