.net5 不支持winform_.NET 5介绍(译文)

原文链接:

Introducing .NET 5 | .NET Blog​devblogs.microsoft.com
.net5 不支持winform_.NET 5介绍(译文)_第1张图片

今天,我们宣布.NET Core 3.0的下一代,将会是.NET 5,也即.NET家族的下一个大版本。从此以后,将只有一个.NET主要版本在前进,你可以将其应用于Windows,Linux,Macos,iOS,Android,tvos,watchos以及web asm还有更多平台上。

我们将在这里介绍.NET 5的部分新API,运行时功能以及语言特性。

.net5 不支持winform_.NET 5介绍(译文)_第2张图片
可以看到,.NET 5取代了原本.net standard应有的位置,因此.net standard可能没有存在的意义

在.NET Core创立之初,我们往这个平台添加了大约5万个.NET Framework的API。.NET Core 3弥合了大量和.NET Framework 4.8之间的功能分歧,启用了winform,wpf和entity framework 6.

.NET 5建立在这一工作上,将.NET Core和Mono最好的一部分组合成一个单独的平台,这样你就可以将其用于你所有的现代.NET代码。

我们计划在2020年11月完成.NET 5,在2020年上半年完成第一个预览版,将支持VS2019,VS for mac以及VSCode的后续更新。

.NET 5:下一代的.NET Core

我们刚才说过,.NET 5是.NET Core的下一代,这个项目目的是在如下几条提升.NET平台:

  • 提供一个单独的,处处可用的.NET运行时和框架,有统一的运行时行为和开发者体验。
  • 将.NET Core,.NET Framework,Xamarin和Mono“去粗取精”,扩展.NET的功能。
  • 将产品构建成单独的代码库,这样微软和社区的开发者可以一起工作,一起扩展.NET,一起实现心中的设想。

这个新项目和它代表的新方向是游戏规则的改变者。用了.NET 5,不管你在构建什么样的应用,你的代码和项目文件感觉上去和看上去都一样。每个app,你都可以得到相同的运行时,api,和语法功能,包含着每天都会提交到corefx里面的新性能提升(目前指.NET Core2.1)。

你所喜欢的.NET Core的一切都会继续存在:

  • 开源,和GitHub的社区向定位。
  • 跨平台的实现。
  • 支持举足轻重(原词leveraging直译杠杆作用)的特定平台功能,例如winform和wpf,以及xamarin在每个原生平台上的原生适配。
  • 高性能。
  • 并行安装(在这里指的应该是可以和旧版本共存)。
  • 小的项目文件(SDK风格)。
  • 强悍的命令行接口(CLI)。
  • VS,VS for Mac,VSCode集成。

这里是一些新特性:

  • 你将可以体会到更多的运行时(比下面的还多)。
  • 所有的平台都可以支持和Java互操作。(微软贼心不死)
  • 多个操作系统上将支持OC和Swift互操作。
  • CoreFX将会被增强,以支持静态编译(AOT),更小的空间占用,支持更多操作系统。

我们将会在9月正式发布.NET Core 3,2020年11月发布.NET 5,然后我们计划每年11月发布一个.NET大版本:

.net5 不支持winform_.NET 5介绍(译文)_第3张图片
不同于Oracle每隔两个大版本长期支持的策略,MS长期支持偶数大版本

我们跳过了.NET Core 4,因为跟现在的.NET Fremework 4.x版本很像,这会让用户误会,而且我们需要清晰地说明:.NET 5是.NET的未来!

我们也有了一个简化命名的机会,想想看,如果只有一个.NET的话,那么很显然不需要一个单独的项目叫“Core”,简单的名字也可以说明,.NET 5有大统一的功能和表现,当然如果你喜欢,就接着用“.NET Core”来称呼也行。(微软是不是在暗示什么?)

运行时体验

Mono是最早的.NET跨平台实现,它一开始的定位是一个.NET Framework的开源代替品,然后转而面向iOS和Android这样的移动设备,是xamarin的运行时。

CoreCLR是.NET Core的运行时(区别于原来的CLR),它一开始是为了支持云应用,包括MS上最大的服务,现在也用于Windows桌面,物联网和机器学习应用。

总而言之,.NET Core和Mono运行时有很多相似之处(毕竟都是.NET),但是也有各自独特的功能,现在有必要挑选一下你想要的开发体验了。我们正在搞CoreCLR和Mono之间的无缝替换,尽可能让这两个运行时之间的切换构建应用变得简单。

接下来的部分,描绘了我们在.NET 5中计划的主要特点,为我们如何演进这两个运行时(无论是独立,还是共同的)提供了清晰的图景。

高吞吐和高效率

很久很久以前,.NET依靠动态编译(JIT)将IL中间码转换成优化的机器码,这以后我们建立了一个工业界领衔的JIT运行时,吞吐量非常高,也允许开发者快速简单的编码。

JIT非常适合长时间运行的云端和客户端解决方案,它们可以针对特定的机器配置生成代码,包括特定的CPU架构。一个JIT可以在运行时重新生成代码,如果方法被频繁调用(它会被动态编译成机器码)生成更快的版本。

我们使http://ASP.NET Core在TechEmpower benchmarks上运行的更快,是个JIT性能不错的有力证明,也是我们在CoreCLR上投资的回报。我们针对容器对.NET Core进行强化的举措,也证明了运行时动态适应限定环境的能力。

应用JIT的开发工具也是个好例子,例如dotnet watch工具。工具经常需要在单个进程中不重启而多次快速编译和加载代码。

使用.NET Core或者Framework的人主要也是依赖JIT的,结果就是,开发体验大致相同。

.NET 5大多数的工作还将依靠基于JIT的CoreCLR运行时,两个特例在于iOS和客户端的Blazor都需要AOT编译。

快速的启动,低占用

Mono在移动项目和游戏上已经投入了大量的努力,它的一个关键功能和接下来的出路就是.NET静态编译器,基于工业界领先的LLVM。Mono AOT编译器允许将.NET代码编译成单体本机exe,像C++一样。AOT编译的应用可以在空间小的场合高效运行,并且在需要时控制启动时的效率。

Blazor已经在使用MonoAOT了,它将是第一批转移到.NET 5的应用之一,我们正在使用它证明这一计划的可行性。

AOT解决方案有两种类型:

  • 第一类:完全的AOT编译。
  • 第二类:绝大多数代码由AOT编译,但是JIT或解释器仍然可用,用于那些AOT不友好的语法(例如泛型)。

MonoAOT两种情况都支持。第一种AOT用于苹果iOS和一些强调安全的游戏主机中,第二种是推荐的选项,因为它提供了AOT的好处,又避免了它的副作用。

.NET Native是我们用在UWP应用的AOT编译器,属于第一类AOT编译器,使用专门的实现,我们限制了你能使用的.NET API和功能。现在的AOT解决方案需要从这里吸取经验教训,覆盖完整的.NET API了。

完全AOT编译依旧会用在iOS,web asm和一些游戏主机上,我们将会将其作为一个构建选项,用在需要快速启动和低占用的应用上。

(译者注:我只想说,我放在这那么大一个CoreRT呢?我猜微软可能会有如下做法:

  1. 放弃CoreRT,将其打散进入MonoAOT中;
  2. MonoAOT将作为CoreRT的“壳”而存在,名为mono,实为core;
  3. 先用MonoAOT顶上,然后在某个版本用CoreRT替代之。)

基础和需求重叠

非常重要的是,我们努力在搞一个全面兼顾启动,吞吐量,内存占用,可靠性与可诊断的平台。同时,也来看看我们的努力吧。我们将在CoreCLR的吞吐量和可靠性,以及MonoAOT编译器的启动速度和体积减小这些指标上投入更多,这样很不错,记住“吞吐量和可靠性”以及“启动速度与空间减小”是齐头并进的。

一些特点值得做更多的投入,但另一些没有。

.NET 5中诊断功能也一样,不管是功能还是性能诊断,去支持同样的硬件和操作系统都很重要(除了iOS和web asm)。

我们将继续在每一个方案和负载上优化.NET 5,不论如何。优化怎么强调都不过分,尤其是有重叠需求的多个负载下。

所有的.NET 5应用都会使用CoreFX框架。我们会确保corefx会在那些今天还没有应用它的项目上运行良好,主要是xamarin和客户端blazor负载。

所有的.NET 5应用都可以用.NET CLI构建,确保你在不同的项目有通用的命令行工具。

C#也会和.NET 5和同步并进,.NET 5的开发者将会接触到最新的C#版本和特性。

.NET 5的诞生

2018年12月,我们在波士顿组建了一个技术团队,开启了这个项目。

来自Mono/xamarin/.net core(也包括unity)的主要设计者们提供了多样的技术和架构方向。

我们现在正以一个有一批产品的团队形式,推进这个项目,自从去年12月以来,我们在一些场合取得了重大进步:

  • 定义了一个极小的层以定义运行时和托管代码层的(互转?),目标是实现超过99%的一般CoreFX代码。
  • Mono虚拟机现在可以使用CoreFX和它的类库。
  • 在Mono虚拟机上使用CoreFX的实现运行所有的CoreFX测试。‘
  • 在Mono虚拟机上运行http://ASP.NET Core 3.
  • 在CoreCLR上运行MonoDevelop和VS for Mac。

将一切都迁移到一个统一的.NET实现上有很多重要问题:目标框架会是什么?Nuget包兼容性规则还会和以前一样吗?哪种负载需要在.NET 5 SDK下开箱即用?如何针对一个特别的架构书写代码?还需要.NET Standard吗?我们在探讨这些问题,不久就会放出设计文档,供大家阅读和反馈。(译者注:如上文,关心CoreRT的人可以尝试由此反馈)

结语

.NET 5是重要且让人兴奋的新方向。你可以看到.NET平台变得更加简单,但是应用范围也更加宽广,功能更强大,也更实用。所有新的开发工作和特性,功能都会是.NET 5的一部分,包括C#新版。

我们看到了使用统一的.NET API和语言来开发多类型,多系统,多硬件应用的光明未来,改动你的构建配置,在不同的环境下例如VS,VS for Mac,VSCode,Azure DevOps或者仅仅在命令行里构建你的应用将非常简单。

热评盘点

我们现在来看看评论区都有些什么好康的:

.net5 不支持winform_.NET 5介绍(译文)_第4张图片

问:Java互操作有什么细节吗,是双向的吗?

答:我们正在投入实现双向交互,单向只有一半的快乐,是吧?(你还想双倍的快乐?)

.net5 不支持winform_.NET 5介绍(译文)_第5张图片

问:请提供真正的F# AOT支持。

答:已经有了,AOT(包括Mono,CoreRT,.Net Native)都支持F#,后面两个的麻烦只在于F#的主要特性过于复杂。Mono的问题更少,但是比起AOT,它不想搞什么大新闻,主要的维护问题在于完善的UWP支持,这是个打包问题,而不是AOT问题。

.net5 不支持winform_.NET 5介绍(译文)_第6张图片

问:好消息!我很好奇关于AOT,F#,泛型和web asm的可能性,而且如果听到通用的/跨平台的,可以运行在网络,移动设备,桌面和物联网的xaml的消息,我会很高兴的。

答:xaml只是个部分ui平台上可选的标记语言,将其通用化没什么用处,这就是这一工作停滞的原因。底层的UI平台有不同的属性和类在控制,所以一个描述它们的标记语言怎么会一样呢?xaml在.net中也带来了很多的困扰,扩增的太过臃肿,但是针对那些和标记语言没关系的东西,xaml用作一个pull request项目(例如“xaml islands”或者“Microsoft.UI.Xaml”)也没什么丢人的。

.net5 不支持winform_.NET 5介绍(译文)_第7张图片

问:大新闻!在这个新时代中,COM互操作会怎么样?

答:和它在.NET Core 3中表现得一样,我们只是添加了将.NET Core类库暴露成COM组件的支持,参看.NET Core 3 pre 5的更新博客。

.net5 不支持winform_.NET 5介绍(译文)_第8张图片
该篇幅略长,只翻译提出者自己说的话(从上图看出,提问者应该是微软另一系统的人或活跃社区支持者)

问:Mono有支持广度,但.Net Core有健壮性(是的我不想翻译成鲁棒性)和性能,所以将它们去粗取精融合起来最好,这是自然而然的一步,但也是需要大量努力的一步,我很高兴微软在实现它。

对于不同的AOT编译器,我的感觉是.NET Native和CoreRT是更高质量的AOT框架,所以我觉得增加对.NET Native/CoreRT的互操作,比把Mono AOT弄得健壮和高效更好,例如“对抗全球变暖,请静态编译你的C#应用”一文中指出,Mono AOT启动时间达300ms(比CoreRT启动时间50ms高了五倍),xamarin应用有明显的一段缓慢。

把第二类AOT(参照上文)作为默认是有道理的,但是在面向消费者的应用中,禁用那些缓慢的东西(例如反射)是很优雅的,最好有个编译器选项来强制执行这些。

答:好主意,我们明年会书写一个AOT的传奇,你会喜欢的。如你所说,我们并不缺少技术。

(完)

你可能感兴趣的:(.net5,不支持winform,vs2019功能介绍)