.net5 不支持winform_.NET 5介绍（译文）
原文链接：
Introducing .NET 5 | .NET Blogdevblogs.microsoft.com
今天，我们宣布.NET Core 3.0的下一代，将会是.NET 5，也即.NET家族的下一个大版本。从此以后，将只有一个.NET主要版本在前进，你可以将其应用于Windows，Linux，Macos，iOS，Android，tvos，watchos以及web asm还有更多平台上。
我们将在这里介绍.NET 5的部分新API，运行时功能以及语言特性。
在.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大版本：
我们跳过了.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呢？我猜微软可能会有如下做法：
- 放弃CoreRT，将其打散进入MonoAOT中；
- MonoAOT将作为CoreRT的“壳”而存在，名为mono，实为core；
- 先用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或者仅仅在命令行里构建你的应用将非常简单。
热评盘点
我们现在来看看评论区都有些什么好康的：
问：Java互操作有什么细节吗，是双向的吗？
答：我们正在投入实现双向交互，单向只有一半的快乐，是吧？（你还想双倍的快乐？）
问：请提供真正的F# AOT支持。
答：已经有了，AOT（包括Mono，CoreRT，.Net Native）都支持F#，后面两个的麻烦只在于F#的主要特性过于复杂。Mono的问题更少，但是比起AOT，它不想搞什么大新闻，主要的维护问题在于完善的UWP支持，这是个打包问题，而不是AOT问题。
问：好消息！我很好奇关于AOT，F#，泛型和web asm的可能性，而且如果听到通用的/跨平台的，可以运行在网络，移动设备，桌面和物联网的xaml的消息，我会很高兴的。
答：xaml只是个部分ui平台上可选的标记语言，将其通用化没什么用处，这就是这一工作停滞的原因。底层的UI平台有不同的属性和类在控制，所以一个描述它们的标记语言怎么会一样呢？xaml在.net中也带来了很多的困扰，扩增的太过臃肿，但是针对那些和标记语言没关系的东西，xaml用作一个pull request项目（例如“xaml islands”或者“Microsoft.UI.Xaml”）也没什么丢人的。
问：大新闻！在这个新时代中，COM互操作会怎么样？
答：和它在.NET Core 3中表现得一样，我们只是添加了将.NET Core类库暴露成COM组件的支持，参看.NET Core 3 pre 5的更新博客。
问：Mono有支持广度，但.Net Core有健壮性（是的我不想翻译成鲁棒性）和性能，所以将它们去粗取精融合起来最好，这是自然而然的一步，但也是需要大量努力的一步，我很高兴微软在实现它。
对于不同的AOT编译器，我的感觉是.NET Native和CoreRT是更高质量的AOT框架，所以我觉得增加对.NET Native/CoreRT的互操作，比把Mono AOT弄得健壮和高效更好，例如“对抗全球变暖，请静态编译你的C#应用”一文中指出，Mono AOT启动时间达300ms（比CoreRT启动时间50ms高了五倍），xamarin应用有明显的一段缓慢。
把第二类AOT（参照上文）作为默认是有道理的，但是在面向消费者的应用中，禁用那些缓慢的东西（例如反射）是很优雅的，最好有个编译器选项来强制执行这些。
答：好主意，我们明年会书写一个AOT的传奇，你会喜欢的。如你所说，我们并不缺少技术。
（完）