概述

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

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

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

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

發布時間表

Release發布日志

1.1	Q4 2016 / Q1 2017
1.2	Q1 2017 / Q2 2017

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的計劃。

序列化

.NET Core將支持大多數序列化器，例如數據契約序列化、XML序列化、JSON.NET以及protobuf-net。而一個被排除在外的重要角色是二進制序列化。

通過這十年來的經驗，我們終于了解到序列化是一項非常復雜的任務，支持序列化的類型在兼容性方面要面對沉重的負擔。因此，我們已經決定讓序列化 成為一種協議，它將在可用的公開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的一部分。我們正在設法讓社區能夠對我們的移植工作提供支持。如果你愿意參與這一項目，請發送郵件至immol@microsoft.com。

詳情說明：Discontinued Technology in .NET Core

轉載于:https://www.cnblogs.com/humble/p/5936590.html

總結

以上是生活随笔為你收集整理的ASP.NET Core官方计划路线及需要废除的一些Framework技术的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。