還有 13 天，蘋(píng)果就要關(guān)上 HTTP 大門(mén)了>>>?  

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

反射

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

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

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

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

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

App Domain

App Domain在CoreCLR中得以實(shí)現，但沒(méi)有在.NET Native中實(shí)現。由于對App Domain的實(shí)現需要大量的運行時(shí)特性支持，因此目前還沒(méi)有任何對它的支持計劃?！皩τ诖a的隔離，我們建議通過(guò)進(jìn)程或容器實(shí)現。而對于程序集的動(dòng)態(tài)加 載，我們建議使用新的AssemblyLoadContext類(lèi)?！?/p>

Remoting

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

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

序列化

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

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

沙箱

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

推薦的替代方案是使用獨立的進(jìn)程，通過(guò)一個(gè)具有有限權限的用戶(hù)賬號運行這些進(jìn)程。通過(guò)這種方式，運行時(shí)不必重復進(jìn)行一些開(kāi)銷(xiāo)較大的權限檢查工作，因為操作系統已經(jīng)為你完成了這方面的任務(wù)。

其他組件

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

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

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

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

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

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

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

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

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

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