虽然有一部分现有的.NET应用程序,尤其是基于ASP.NET
MVC的应用程序将能够比较简单地迁移至.NET
Core,但另一部分.NET应用在迁移过程中可能会遇到某些问题。有一些问题是显而易见的,例如从WinForms或WPF应用迁移至
Universal Windows
Applications(UWP),而另一类些问题则更加微妙,这关系到.NET
Framework核心功能中更底层的实现。

看了个BUILD的PPT,Windows Runtime
(RT)并不是一些新闻网站说的那样微软自废.NET武功,而是恰恰相反,WinRT是Win32API的现代版,其中有很深的.NET的基因,是Metro
UI的.NET基础,如果考察Metadata的变化,WinRT的API定义的元数据是基于标准ECMA
335,也就是.NET的标准
,WinRT也是一个沙箱的环境,针对AppStore环境设计的。

反射

基础知识

反射API在.NET
Core中产生了很大的变化。正如在WinRT中的应用方式一样,反射功能被分成一种轻量级的版本以及一种开销更大的版本。来自微软的Immo
Landwerth写道:

微软以推出Windows
8为契机,以解决Windows长期存在的问题,并带来了新的用户界面,使得Windows更加安全和AppStore的商业模式。微软在Windows
8 里打造了第三个 XAML-based UI 系统, WPF只是一个供 .NET
这个圈子使用的XAML UI系统 Silverlight只是给浏览器使用的XAML
UI系统,Windows
Phone7将Silverlight到了手机,现在将XAML带到了涵盖PC、Pad、Phone的所有系统(虽然微软认为平板也是PC,我还是想叫他Pad,用过iPad的都知道苹果所定义的Pad和PC有很大区别)。

在推出.NET
Native时,我们利用了一种技术,它允许我们将应用与框架和第三方依赖进行静态链接。要使这种链接功能可行,它必须能够找出在你的应用没有使用的那部
分框架功能。对于其他技术,例如C++来说,这一过程并不复杂,因为这种系统并不具备反射这样的动态能力。当然,在.NET
Native中仍然支持反射,但我们希望让这个平台尽可能地降低开销,也就是说不必为你所不需要的特性增加开销。这一点对于反射来说尤其明显,因为它对于
运行时以及编译器能够基于静态信息进行哪些操作施加了极大的限制。

因此,在理想的情况下,反射应当作为.NET
Core中一个可选的组件,你可以选择在自己的应用中完全放弃使用它。麻烦在于,System.Object在进行Object.GetType()操作
时将对反射产生依赖。为了打破这种依赖,我们决定让System.Type不再展现整个反射类型信息,而仅仅展示类型的名称。这也意味着在.NET
Core中的System.Type不再包括GetMembers()等API,但仍然会暴露Name等API。

.NET开发人员都对.NET 的P / Invoke和COM Interop
很熟悉了,这两种技术使得.NET人员可以使用Win32
API和COM组件,Mono也是使用P/Invoke技术创建原生的库,例如Gtk# 绑定到
Gtk+ API, MonoMac 绑定到Cocoa API, Qyoto 绑定到Qt
API,Mono出现了MonoTouch,MonoDroid和MonoMac等等很有创新性的产品。 COM
Interop 还可以使得C/C++ 从 C#导入Com类型库。

通过一个名为GetTypeInfo的扩展方法,可以得到在一般情况下能够从Type对象中获取的信息。TypeInfo类所包含的信息没有原来那么丰富,但微软最近决定在.NET
Core中重新引入一部分反射API,这部分变更是超出原先计划之外的。

创建原生库的方法很多,但是这些工作都得是手工去做,很乏味而且容易出错,从这点来说WinRT也是一个很有创新的,可以让所有的开发者用同一个模型创建Metro
UI的应用。

为了使代码更容易进行移植,.NET
4.5及之后的版本提供了对TypeInfo的某种支持,它与在.NET
Core中使用的版本相类似。

WinRT

App Domain

WinRT是一个新的API 集合,具有以下特性:

App Domain在CoreCLR中得以实现,但没有在.NET Native中实现。由于对App
Domain的实现需要大量的运行时特性支持,因此目前还没有任何对它的支持计划。“对于代码的隔离,我们建议通过进程或容器实现。而对于程序集的动态加
载,我们建议使用新的AssemblyLoadContext类。”

  • 它实现了Metro UI规范的UI库
  • 为Windows开发人员提供一个简单的UI编程模型,你不需要学习Win32API的那些复杂的API了
  • 它使用XAML-base的UI系统
  • 澳门新葡亰,API都设计成了异步的
  • 它和.NET一样是个沙箱的API,自成体系,用于创建AppStore上的应用程序。
  • API的元数据格式是ECMA335,和.NET一样的标准。这是不是意味着以后Mono也可以在xUnit上去实现这样的API呢?

Remoting

WinRT包装的新的用户界面系统,和Win32API一样是Com的上层。

现如今,已经很少有开发者还能够记起Remoting库的存在,更不要说如何使用它了。即使还有人在使用,他们也一直在抱怨它的性能、高复杂性以及总体表现的脆弱性。

WinRT Projections

如今,多个.NET应用在同一台机器上的通信基本都被WCF所取代,后者能够带来更好的性能,可用于管道或内存映射文件。对于跨机器的通信,微软推荐“使用一种低开销的纯文本协议,例如HTTP”。因此,微软并没有在.NET
Core中支持Remoting的计划。

我们所说的“Binding”,微软现在叫做“Projections”,又是一个新名词。Projections就是向三个环境
Native (C and C++), HTML/Javascript 和.NET
暴露接口的过程。所以在Win8上各类开发者依然可以用着不同的工具,但是却是使用着统一的模型。

序列化

如果开发者使用.NET或者C++
写的组件,它的API被存储在一个WinMD文件里,你可以在三种环境(原生、javascript和.NET)。即使你的组件是用C++
写的,也不需要通过COM向外暴露,使用起来更像是一个面向对象的C++ API。

.NET
Core将支持大多数序列化器,例如数据契约序列化、XML序列化、JSON.NET以及protobuf-net。而一个被排除在外的重要角色是二进制序列化。

WinRT的底层定义了一套基本的类型和各种环境的映射,这是不是很像.NET环境里面对不同语言的支持哈。

通过这十年来的经验,我们终于了解到序列化是一项非常复杂的任务,支持序列化的类型在兼容性方面要面对沉重的负担。因此,我们已经决定让序列化
成为一种协议,它将在可用的公开API的基础上实现。然而,二进制序列化的实现需要对类型本身的深入了解,因为这种方式可以对整个对象图进行序列化,甚至
包括私有的状态信息。

异步API

沙箱

微软认为,当给开发者一个使用同步和异步的API的选择的时候,开发者会选择简单的同步API,这在我们的.NET
编程实践中得到证明,.NET有很成熟的异步编程模型,还有特意为并行和异步处理而设计的F#,结果是什么呢,各位同学心里有数。

网站地图xml地图