在Linux和Mac OS X系统上运行.NET

.NET Core运行时已经看到了实现真正的跨平台的美好前景,它最终出现在Linux和Mac OS X平台上。在Microsoft Build大会上,来自微软的项目经理Habib Heydarian为听众分析了这一举措对开发者们所带来的益处,并告诉开发者们如何开始探索这些新的机会。在名为“让.NET实现跨平台”的一场讲座中,Heydarian首先介绍了开发者如何进行一次全新的.NET Core安装。

首先,所有的.NET代码都包含在一个单独的文件夹中,而无需将它安装在某个系统级别的位置。这样,只要愿意,每个.NET应用都可以使用一个完全不同的编译版本。并且在Windows系统上进行编译的代码也能够在Mac OS X和Linux系统上运行。

要在以上系统中运行一个基于命令行的标准HelloWorld程序,可使用以下方式:

./corerun HelloWorld.exe

// corereun是一个原生的运行app的环境

// 在Windows上,引导.NET应用的功能已经内建于操作系统中了

在非Windows平台上使用.NET,就意味着开发者们能够使用ASP.NET 5、CoreCLR,并且从以下共享的功能中受益了:

  1. 运行时组件
    1. 64位的JIT编译器与SIMD指令
    2. 垃圾回收器
  2. 类库
    1. 基础类库
    2. NuGet包
  3. 编译器
    1. .NET编译器平台(Roslyn)

如何获取.NET Core

对于Mac OS X开发者来说,推荐的方式是使用Homebrew以获取必要的组件。当安装好Homebrew之后,就可以通过以下命令获取.NET组件了:

brew tap aspnet/dnx
brew update
brew install dnvm
dnx . kestrel

Linux用户可以从该项目的网站上下载一个包含了所有必要组件的TAR文件,随后按照以下方式进行安装:

tar zxvf PartsUnlimited-demo-app-linux.tar.gz -C ~/
source ~/.dnx/dnvm/dnvm.sh
dnvm use 1.0.0-beta5-11624 -r coreclr -arch x64
dnx . kestrel

你一定注意到了一点,在这个两个平台上所运行的最后一条指令都是kestrel的执行。Kestrel也正是“跨平台的ASP.NET 5 web服务器”,DNVM则是.NET的版本管理器。目前,该项目只支持64位平台的Linux和Mac OS X。开发团队仍然在继续研究如何让它支持32位的系统。

紧随Linux和Mac OS X之后,对FreeBSD的支持最近也加入到该项目中。对于这三个平台来说,目前还存在着一个限制,那就是从源代码编译.NET Core的功能仅限于Windows版本。要从源代码编译.NET,开发者需要首先编译CoreCLR,然后再编译CoreFX。

正如Windows平台上的.NET开发者能够利用平台调用(PInvoke)功能一样,Linux平台上的开发者也能够使用DLL Import这一命令:

[DllImport(“libc”)]
private static extern int printf(string format);

Printf(“Hello, //BUILD 2015!\n”);

下一步计划

Heydarian在演讲余下的部分谈到了该团队下一步的计划,以及微软对这一项目的目标。随着Visual Studio不断地扩展到非Windows的平台上,微软希望能够改进在这些新环境中的调试功能。对于VS2015来说,就是要实现远程调试。而对于VS Code来说,首先要从实现本地调试开始。

另一个改进的方向是整体的上线预备。为了在这方面有所突破,团队打算整合MSBuild的支持,并消除目前对Mono在这方面功能的依赖。

Heydarian表示,当.NET在Linux和Mac OS X平台上正式发布,并成为“RTM”版本之后,微软将做出以下正式的承诺:

  1. .NET Core应用能够在基于Linux的生产环境中运行,包括Docker、本地部署和云端部署
  2. 开发者可以使用VS Code或其它任何喜爱的编辑器,对运行在Mac OS X环境中的.NET代码进行编辑、编译与调试
  3. 全部使用无关平台特性创建的应用在Windows与其它平台上具有相同的行为
  4. .NET Core将把现有.NET云端生态系统的类库也带到Linux上
  5. 微软对.NET在Linux上的支持、服务和维护与其它微软产品一视同仁

在你的应用中加入对Linux和Mac OS X的支持

微软将推出一套API可移植性工具,用于对现有的代码进行分析,找出所需的程序集和目标平台。目前为止,唯一对兼容性进行了测试的Linux分发平 台是Ubuntu 14.04.2 LTS。虽然没有明确地表示不支持其它的Linux分发平台,但无法保证在这些平台上是否能够正常运行。

Heydarian认为目前来看,微软所提供的.NET与Mono版本相比,所针对的市场方向并不相同。Haydarian表示:“……虽然 [Mono]在移动场合的表现优秀,但它并不是为服务器或云端生产环境的使用场景而设计的……”,而.NET Core倾向于在具有高吞吐量、高伸缩性,以及更高的修复前平均时间(MTTF)的服务器环境中所使用。

希望通过.NET即将提供的功能,从跨平台方式中受益的开发者可以首先从VS2015RC中的ASP.NET 5项目模板开始打造及测试应用,并且参考GitHub上的ASP.NET示例应用Parts Unlimited。凡是能够在Windows上的ASP.NET 5中成功运行的应用,一旦等到.NET Core RTM之后,就能够无缝地迁移至Linux平台上。

.NET 4.6中的性能改进

.NET 4.6中带来了一些与性能改进相关的CLR特性,这些特性中有一部分将会自动生效,而另外一些特性,例如SIMD与异步本地存储(Async Local Storage)则需要对编写应用的方式进行某些改动。

SIMD

Mono团队一直以他们对SIMD,即单指令流多数据流特性的支持引以为傲。SIMD是一种CPU指令集,它能够在同一时间对最多8个值进行同一操作。而随着.NET CLR版本4.6的推出,Windows开发者终于也能够使用这一特性了。

为了实际观察一下SIMD的效果,可以参考一下这个示例。假设你需要通过c[i] = a[i] + b[i]这种形式对两个数组进行相加,以得到第三个数组。通过使用SIMD,你可以按照以下方式编写代码:

for (int i = 0; i < size; i += Vector.Count)
 {
     Vector v = new Vector(A,i) + new Vector(B,i);
     v.CopyTo(C,i);
 }

请注意这个循环是如何按Vector<int>.Count的取值进行递增的,根据CPU类型的不同,它的取值可能是4或是8。.NET JIT编译器将根据CPU的不同生成相应的代码,以4或8的值对数组进行批量相加。

这种方式看起来有些繁琐,因此微软还提供了一系列辅助类,包括:

程序集卸载

恐怕大多数开发者都不知道这一点:.NET经常会对同一个程序集加载两次。发生这种情况的条件是.NET首先加载了某个程序集的IL版本,随后又加 载了同一程序集的NGEN版本(即预编译版本)。这种方式对于物理内存来说是相当严重的浪费,尤其是对诸如Visual Studio这样的大型32位应用程序来说更为明显。

而在.NET 4.6中,一旦CLR加载了某个程序集的NGEN版本,它会自动清空对应的IL版本所占用的内存。

垃圾回收

在.NET 4.6中,你将能够通过一种更精密的方式临时中止垃圾回收器的运作,新的TryStartNoGCRegion方法允许你指定在小对象以及大对象的堆中需要多少内存。

如果出现内存不足的情况,运行时将会返回false,或是停止运行,直到通过GC清理得到足够的内存为止。你可以通过为 TryStartNoGCRegion传入某个标记的方式控制这一行为,如果你成功地进入了某个无GC区域(在过程结束前不允许进行GC),那么在过程结 束时必须调用EndNoGCRegion方法。

在官方文档中并没有说明该方法是否是线程安全的,不过考虑到GC的工作原理,你应当尽量避免让两个进程同时尝试改变GC状态的做法。

对于GC的另一项改进是它处理pinned对象(即一旦分配后不可移动位置的对象)的方式。虽然在文档中对此方面的描述有些语焉不详,但当你固定了某个对象的位置时,通常也会固定其相邻对象的位置。Rich Lander在文中写道:

GC将以一种更优化的方式处理pinned对象,因此GC能够将pinned对象周围的内存进行更有效地压缩。对于大量使用pin方式的大规模应用来说,这一改动将极大地改进应用的性能。

GC对于如何使用较早的几代中的内存方面也体现出更好的智能性,Rich继续写道:

第1代对象升级为第2代对象的方式也得到了改进,以更有效地使用内存。在为某一代分配新的内存空间之前,GC会先尝试使用可用的空间。同时,在利用可用空间区域创建对象时使用了新的算法,使新分配的空间大小比起从前更接近于对象的大小。

异步本地存储

最后一项改进与性能并没有直接的关系,但通过有效的利用仍然能达到优化的效果。在异步API还没有流行起来的年代,开发者可以利用线程本地存储 (TLS)缓存信息。TLS对于某个特定的线程来说就像是一种全局对象,这意味着你可以直接访问上下文信息并进行缓存,而无需显式地传递某种上下文对象。

而在async/await模式中,线程本地存储就变得毫无用武之地了。因为每次调用await的时候,都有可能跳转至另一个线程。而且即便侥幸避开了这种情况,但其它代码也有可能跳转到你的线程中并干扰TLS中的信息。

新版本的.NET引入了异步本地存储(ALS)机制以解决这一问题,ALS在语义上等价于线程本地存储,但它能够随着await的调用进行相应的跳转。这一功能将通过AsyncLocal泛型类实现,其内部将调用CallContext对象用于保存数据。

Entity Framework 7中的影子属性

影子属性是类本身中并不存在,但Entity Framework却认为存在的字段。它们能够参与查询、创建/更新操作和数据库迁移。微软认为影子属性有两个主要的应用场景:

  • 允许数据访问层访问那些不该由领域模型暴露到应用其它部分的属性
  • 允许开发者高效地添加属性到没有源代码的类中

影子属性在OnModelCreating事件中被定义,该事件在DBContext中为可重载方法。这里有一个绑定DataTime属性LastUpdated到Blog实体的例子。

protected override void OnModelCreating(ModelBuilder modelBuilder)
{
    modelBuilder.Entity().Property("LastUpdated");
}

这个属性的一个通用用例是在执行保存操作时自动赋值给LastUpdated属性。为此,你可以使用DBContext.ChangeTracker来获取DBEntry类型的对象列表。你可以这样写:

foreach (var item in modifiedEntries)
{
    Item.Property("LastModified").CurrentValue = DateTime.Now;
}

一般可以通过重载DBContext类的SaveChanges()方法实现。通过这里的重载,你可以更新所有需要更新的数据,而又不必在每一个更新数据的地方重复代码。

当ChangeTracker适合用于修改保存事件的时候,你会很想绕过DBEntry直接访问影子属性。通过EF.Property函数就可以做到,如下所示:

EF.Property(entity, "LastModified")

这个表达式放在一个查询中能生成服务器端的WHERE和ORDER BY子句。

ASP.NET 5与MVC 6中的新特性

虽然人们的目光都专注于ASP.NET 5与跨平台的执行引擎上,但作为微软推荐的UI与Web Service框架,MVC也引入了多项变更。其中最重要的一点莫过于MVC、Web API与Web Pages三者的统一了。

差点忘了提一句,MVC 6中默认的渲染引擎Razor也将得到更新,以支持C# 6中的新语法。而Razor中的新特性还不只这一点。

在某些情况下,直接在Web页面中嵌入某些JSON数据的方式可能比向服务端发起一次额外请求的方法更合适。在之前的版本中,实现这一点需要编写一 些繁琐的映射代码,然后用某种JSON转换器对数据对象进行序列化,并将结果通过view model进行暴露。而在MVC 6中,以上所有的样板代码都可以简化为一句“@Json.Serialize(Model)”。

在实现图片缓存时,同样也会遇到大量样板代码的问题。图片的缓存本身很简单,但要找到某种方式通知浏览器让缓存失效,往往要用到许多繁琐的临时方 案。而通过使用全新的Image Tag Helper,只需将asp-file-version这一属性设置为true就可以了,MVC将“自动为图片文件名附加上一个用于清除缓存的版本号”。

Tag Helper框架也得到了一定程度的改进,用户现在可以“将Tag Helper中的服务端属性与Dictionary的属性进行绑定”。服务端属性的存在与否,将使Tag Helper选择性地生效。如果想要了解更多如何编写自定义Tag Helper的内容,请参考Jeff Fritz的文章“开始使用ASP.NET MVC Tag Helper”。

路由token能够让你在类级别编写类似于“[Route(“Products/[action]”)”这样的表达式,而在MVC 6中,可以在路由名称中使用相同的token,这一点对于诊断过程来说很有帮助。