虽然有一部分现有的.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#,结果是什么呢,各位同学心里有数。

从理论上说,沙箱是一种优秀的思想,它允许部分信任代码以安全的方式执行。但在实践中,要想正确地应用它非常困难,哪怕是一点点微小的错误,也会导
致安全性方面的漏洞。Immo
Landwerth还表示,它“使实现变得更加困难,并且经常会给未使用沙箱的应用的性能带来负面影响。”

在WinRT中,微软一直遵循一个简单的规则:如果一个API预计耗时超过50毫秒,那么API就是异步的,也就是说API是异步的哦,这样就能确保Metro
UI上的操作体验是最好的。

推荐的替代方案是使用独立的进程,通过一个具有有限权限的用户帐号运行这些进程。通过这种方式,运行时不必重复进行一些开销较大的权限检查工作,因为操作系统已经为你完成了这方面的任务。

异步编程历来是一个繁琐的过程,回调和状态,还有异常处理等。为了简化这个过程,C#和VB也扩展了支持
F#-inspired await/async 模型,异步编程变成了欢乐之旅。

其他组件

.NET的首要地位不见了吗?

微软正考虑将下表中列举的组件进行开源,并移植到.NET Core。

之前的新闻中一直在质疑.NET 被微软抛弃了,当然不是了。也不是所有的.NET
API 都集成到了WinRT中,只是一个子集。

  • 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、并实例化描述对象图的功能。

当你使用C#和VB,你使用的是完整的.NET框架。但是他们只暴露了一个较小的子集API给Windows
8的开发者。你可能会想,我可以通过一些技巧使用到整个.NET,如果你的程序不需要提交AppStore上接受微软的审核,这是可以的。这种策略明显是跟苹果学的。

你是否有兴趣帮助我们移植某个组件?.NET
Framework实现的部分源代码已经通过MIT许可进行了开源,作为Reference
Source的一部分。我们正在设法让社区能够对我们的移植工作提供支持。如果你愿意参与这一项目,请发送邮件至immol@microsoft.com。

借此机会.NET团队也对.NET做了一次清理,mscorlib.dll和System.dll中已被分割在不同的库里头了,随着Win8发布的.NET版本是4.5了,也就是说.NET
4.5不是.NET
4的简单补丁包,里头加了不少东西,ASP.NET的版本号也是4.5,不像.NET 2.0
~3.5 SP1,ASP.net的版本还是2。0。为了在Win8里开发,开始学习.NET
4.5又是必须的了,这里关注的集中在客户端开发,同样的在服务器端开发方面.NET
4.5也加入大量的干货。

查看英文原文:Discontinued Technology in .NET
Core

创建WinRT 组件

稿源:InfoQ

虽然WinRT支持很多的语言,但是微软只是用C++和.NET演示了如何开发一个WinRT组件,使用.NET来开发WinRT组件会比C++简单得多。也不是所有的.NET特性都能用上哦,比如组件类就不能使用private
字段,在异步的API里不能使用Task<T> ,要用IAsyncOperation 代替。

public sealed class AddTwo
{
       public int Add (int a, int b)
       {
           return a + b;
       }

       public async IAsyncOperation SubAsync (int a, int b)
       {
           return a - await (CountEveryBitByHand (b));
       }
   }

你会发现上述代码没有任何形式的COM声明,唯一限制的是,类必须是个密封的(除非你是在创建一个XAML
UI组件,这种情形下这种限制是接触的)

UI编程

当涉及到用户界面的开发的时候,你你可以使用HTML与CSS样式或使用XAML的你的应用程序的用户界面。当你回到界面层,就可以用HTML
& CSS或者是XAML UI,用HTML&
Css做出来的界面就是Web了,而是一个Windows应用,早在Vista开始就有了类似的应用,Windows7上做了改进,叫做Gadgets
,Windows 8就进化到了Metero UI,和C++、.NET并驾齐驱了。

Windows8的开发框架并没有基于HTML5和JavaScript,开发者完全可以用原生C++、C#和Silverlight去开发对平板和触控友好的应用,HTML5和JavaScript只是提供了一种选择。

图片 1

作者: 自由、创新、研究、探索……
出处: