概述

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

作為.NET Core這么大的一個(gè)項(xiàng)目,很難準(zhǔn)確預(yù)測(cè)每一個(gè)計(jì)劃的是否有變動(dòng).

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

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

發(fā)布時(shí)間表

Release發(fā)布日志

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

Release 版本特性

1.1

• URL 重寫中間件
• Response 緩存中間件
• 第三方DI支持的實(shí)現(xiàn)
• WebListener 服務(wù)器(Windows only)
• MVC filters中間件
• Tag Helpers
• View 預(yù)編譯
• 基于Cookie的TempData provider 改進(jìn)Azure
  • App Service 啟動(dòng)時(shí)間改進(jìn)
  • App Service 日志provider
  • Azure 密鑰存儲(chǔ)庫(kù)?provider

1.2

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

廢除技術(shù)概述

雖然有一部分現(xiàn)有的.NET應(yīng)用程序，尤其是基于ASP.NET MVC的應(yīng)用程序?qū)⒛軌虮容^簡(jiǎn)單地遷移至.NET Core，但另一部分.NET應(yīng)用在遷移過程中可能會(huì)遇到某些問題。有一些問題是顯而易見的，例如從WinForms或WPF應(yīng)用遷移至 Universal Windows Applications（UWP），而另一類些問題則更加微妙，這關(guān)系到.NET Framework核心功能中更底層的實(shí)現(xiàn)。

反射

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

在推出.NET Native時(shí)，我們利用了一種技術(shù)，它允許我們將應(yīng)用與框架和第三方依賴進(jìn)行靜態(tài)鏈接。要使這種鏈接功能可行，它必須能夠找出在你的應(yīng)用沒有使用的那部 分框架功能。對(duì)于其他技術(shù)，例如C++來說，這一過程并不復(fù)雜，因?yàn)檫@種系統(tǒng)并不具備反射這樣的動(dòng)態(tài)能力。當(dāng)然，在.NET Native中仍然支持反射，但我們希望讓這個(gè)平臺(tái)盡可能地降低開銷，也就是說不必為你所不需要的特性增加開銷。這一點(diǎn)對(duì)于反射來說尤其明顯，因?yàn)樗鼘?duì)于 運(yùn)行時(shí)以及編譯器能夠基于靜態(tài)信息進(jìn)行哪些操作施加了極大的限制。

因此，在理想的情況下，反射應(yīng)當(dāng)作為.NET Core中一個(gè)可選的組件，你可以選擇在自己的應(yīng)用中完全放棄使用它。麻煩在于，System.Object在進(jìn)行Object.GetType()操作 時(shí)將對(duì)反射產(chǎn)生依賴。為了打破這種依賴，我們決定讓System.Type不再展現(xiàn)整個(gè)反射類型信息，而僅僅展示類型的名稱。這也意味著在.NET Core中的System.Type不再包括GetMembers()等API，但仍然會(huì)暴露Name等API。

通過一個(gè)名為GetTypeInfo的擴(kuò)展方法，可以得到在一般情況下能夠從Type對(duì)象中獲取的信息。TypeInfo類所包含的信息沒有原來那么豐富，但微軟最近決定在.NET Core中重新引入一部分反射API，這部分變更是超出原先計(jì)劃之外的。

為了使代碼更容易進(jìn)行移植，.NET 4.5及之后的版本提供了對(duì)TypeInfo的某種支持，它與在.NET Core中使用的版本相類似。

App Domain

App Domain在CoreCLR中得以實(shí)現(xiàn)，但沒有在.NET Native中實(shí)現(xiàn)。由于對(duì)App Domain的實(shí)現(xiàn)需要大量的運(yùn)行時(shí)特性支持，因此目前還沒有任何對(duì)它的支持計(jì)劃。“對(duì)于代碼的隔離，我們建議通過進(jìn)程或容器實(shí)現(xiàn)。而對(duì)于程序集的動(dòng)態(tài)加 載，我們建議使用新的AssemblyLoadContext類。”

Remoting

現(xiàn)如今，已經(jīng)很少有開發(fā)者還能夠記起Remoting庫(kù)的存在，更不要說如何使用它了。即使還有人在使用，他們也一直在抱怨它的性能、高復(fù)雜性以及總體表現(xiàn)的脆弱性。

如今，多個(gè).NET應(yīng)用在同一臺(tái)機(jī)器上的通信基本都被WCF所取代，后者能夠帶來更好的性能，可用于管道或內(nèi)存映射文件。對(duì)于跨機(jī)器的通信，微軟推薦“使用一種低開銷的純文本協(xié)議，例如HTTP”。因此，微軟并沒有在.NET Core中支持Remoting的計(jì)劃。

序列化

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

通過這十年來的經(jīng)驗(yàn)，我們終于了解到序列化是一項(xiàng)非常復(fù)雜的任務(wù)，支持序列化的類型在兼容性方面要面對(duì)沉重的負(fù)擔(dān)。因此，我們已經(jīng)決定讓序列化 成為一種協(xié)議，它將在可用的公開API的基礎(chǔ)上實(shí)現(xiàn)。然而，二進(jìn)制序列化的實(shí)現(xiàn)需要對(duì)類型本身的深入了解，因?yàn)檫@種方式可以對(duì)整個(gè)對(duì)象圖進(jìn)行序列化，甚至 包括私有的狀態(tài)信息。

沙箱

從理論上說，沙箱是一種優(yōu)秀的思想，它允許部分信任代碼以安全的方式執(zhí)行。但在實(shí)踐中，要想正確地應(yīng)用它非常困難，哪怕是一點(diǎn)點(diǎn)微小的錯(cuò)誤，也會(huì)導(dǎo) 致安全性方面的漏洞。Immo Landwerth還表示，它“使實(shí)現(xiàn)變得更加困難，并且經(jīng)常會(huì)給未使用沙箱的應(yīng)用的性能帶來負(fù)面影響。”

推薦的替代方案是使用獨(dú)立的進(jìn)程，通過一個(gè)具有有限權(quán)限的用戶帳號(hào)運(yùn)行這些進(jìn)程。通過這種方式，運(yùn)行時(shí)不必重復(fù)進(jìn)行一些開銷較大的權(quán)限檢查工作，因?yàn)椴僮飨到y(tǒng)已經(jīng)為你完成了這方面的任務(wù)。

其他組件

微軟正考慮將下表中列舉的組件進(jìn)行開源，并移植到.NET Core。

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

• System.DirectoryServices。.NET Core目前并不支持通過該組件與LDAP或活動(dòng)目錄進(jìn)行通信。

• System.Drawing。雖然從嚴(yán)格意義上來說，它應(yīng)該屬于一種客戶端API，但還是有大量開發(fā)者在服務(wù)端通過繪圖API實(shí)現(xiàn)縮略圖或水印的生成。我們目前還不支持在.NET Core中使用這些API。

• System.Transactions。雖然ADO.NET支持事務(wù)，但并不包括對(duì)于分布式事務(wù)的支持，后者包括氛圍事務(wù)（ambient transaction）及資源征集（enlistment）的概念。

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

• System.Net.Mail。目前還不支持在.NET Core中通過這些API實(shí)現(xiàn)電子郵件的發(fā)送。

• System.IO.Ports。.NET Core目前還不支持與串行化端口的通信。

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

• System.Xaml。在開發(fā)UWP應(yīng)用時(shí)，開發(fā)者將使用WinRT XAML API。因此，.NET Core目前并不支持托管XAML框架，后者包括解析XAML、并實(shí)例化描述對(duì)象圖的功能。

你是否有興趣幫助我們移植某個(gè)組件？.NET Framework實(shí)現(xiàn)的部分源代碼已經(jīng)通過MIT許可進(jìn)行了開源，作為Reference Source的一部分。我們正在設(shè)法讓社區(qū)能夠?qū)ξ覀兊囊浦补ぷ魈峁┲С帧Ｈ绻阍敢鈪⑴c這一項(xiàng)目，請(qǐng)發(fā)送郵件至immol@microsoft.com。

詳情說明：Discontinued Technology in .NET Core

轉(zhuǎn)載于:https://www.cnblogs.com/humble/p/5936590.html

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。