写点什么

.NET 生态系统概览

2019 年 9 月 19 日

.NET生态系统概览

本文要点

  • .NET 5 预计会在 2020 年发布,届时将统一所有.NET 平台。

  • 在进行特性开发时优先考虑性能。

  • C#语言的发展直接推动了开发者的采用。

  • 开源社区让.NET 生态系统变得更好。


2002 年,.NET 发布。在接下来的 12 年多时间里,.NET 开发社区以看似稳定的速度增长。然后,情况开始迅速变化。微软预见到了生态系统的变化,采纳了开源开发理念,甚至收购了 GitHub。出现这样的变化,说明 .NET Framework 开发人员已经准备好迎接刚刚开始的加速发展。微软后来收购了全球领先的软件开发平台 GitHub,而 .NET Framework 开发人员也做好了迎接加速发展的准备。


2014 年 11 月,.NET Core 诞生。对于.NET 生态系统来说,这预示着一个革命性的开源新时代的到来,但这并非一帆风顺。困惑和沮丧随之而来;开发人员还没有准备好迎接如此巨大的变化。为了消除这种困惑,睿智的.NET 团队产品经理 Immo Landwerth 开始着手创建一系列视频,解释 .NET Standard、.NET Core、.NET Framework 和新的.NET 生态系统的各种细节——通常是坐在温暖的火炉旁,手里拿着苏格兰威士忌。尽管这看起来很惬意,但我认为,如果一位微软的 PM 愿意坐在火炉旁解释一些事情,这是一个令人担忧的迹象。


.NET Standard

开发人员必须了解 .NET Standard,但是多年以后,.NET Standard 仍然让那些不知道如何使用它的人感到困惑——他们将它误认为运行时,而它实际上只是一个规范。作为一个目标框架别名(TFM),开发人员可以编写面向 .NET Standard 的类库,并使生成的包可以供 .NET Core 或 .NET Framework 应用程序使用。考虑下多平台。借助编译器指令,包的作者可以编写条件代码,以 .NET Core 或 .NET Framework 为编译目标。这种标准化可以提供多种满足标准的实现。使用 .NET Standard,版本可以与 .NET Core 和 .NET Framework 实现保持一致。


.NET Standard 是一个规范。它代表所有.NET 平台都必须实现的一组 API。

——Immo Landwerth


想象一下代码维护;感觉如何——一个有趣的概念,但并非没有一点焦虑。


统一 .NET Core 和 .NET Framework

Landwerth 做了一项了不起的工作,视频也非常有用,但现在微软又开始转向了。在 2019 年微软 Build 大会上,他们发布了 .NET 5,统一了 .NET Core 和 .NET Framework。


以后将只有一个 .NET,你可以使用它开发面向 Windows、Linux、macOS、iOS、Android、 tvOS、watchOS、WebAssembly 等平台的应用。

——Richard Lander


是的,没错,但值得再重复一遍,.NET 5 的目标是统一 .NET Framework 和 .NET Core。要使这一公告成为现实还有许多工作要做。2019 年是不可能实现的,所以期待 2020 年吧。这将给开发人员社区带来极大的帮助,因为它让事情变得简单!


微软还利用了Mono运行时和 .NET Core 的成果。乍一看可能有点吓人(再强调一遍,作为开发人员,我们需要拥抱变化而不是害怕它),但是请放心,为实现 .NET 5 所做的所有工作都是以 .NET Core 和 Mono 的成功经验为基础。.NET 的统一在真正意义上终结了过去多年来困扰开发人员社区的.NET 生态系统分裂的问题。目前还不清楚 .NET Standard 是否会继续存在。


未来展望

虽然我们很容易沉溺于过去,对过去的担忧和挫折牢骚满腹,但我们必须前进。也许,最合理的方法之一就是统一 .NET Core 和 .NET Framework……我敢说:“让 .NET 再次变得伟大!”也许我的说法太过了,但我们还是讨论一下未来吧。微软将把我们引向何方?


让我们先退一步,讨论一下我们从哪里来,然后再深入讨论我们要到哪里去。并不是所有的.NET 开发人员都知道他们的代码是如何编译的以及最终生成了什么。


从一开始.NET 就是基于即时(JIT)编译器将中间语言(IL)翻译成最优的机器码。

——Richard Lander


回顾我之前提到的 Mono 项目,我们知道,在.NET 预编译(AOT)方面已经做了大量的工作。Mono 已经实现了业界领先的LLVM编译器基础设施。


Mono AOT 编译器可以将.NET 代码编译成一个可以在机器上运行的本地可执行代码,就像 C++代码一样。

——Richard Lander


重要的是要认识到,在 .NET 3.0 之后,不会再移植任何 .NET Framework 特性。再说一次,.NET 5 预计在 2020 年 11 月推出,所以时间是一个重要的因素。虽然这看起来可能是很长一段时间以后的事,但它会很快就会到来。你可以问下自己,“在此期间我们应该做些什么?”我们下次再讨论这个问题。


以性能为中心的创新

微软官方建议您在此期间开始使用 .NET Core 开发新应用程序。如果可能的话,考虑将现有的 .NET Framework 应用程序移植到 .NET Core 也是一个好主意。


新应用程序应该基于 .NET Core 构建。未来针对 .NET 的投入都将投入到 .NET Core 上。

——Scott Hunter


在.NET 生态系统中,.NET Core 一直处于创新的中心。它是一种可以替代 .NET Framework 的运行时,从头开始进行了完全重写;这使得针对性能的积极创新成为可能。 .NET Core 和 ASP . NET Core 的每次迭代都会在保证一致性的情况下进行改进。“减少分配”是一个非常常见的主题,为的是提升性能。一个新的行业术语诞生了:


Allocaty(形容词:al·lo·caty)——进行不必要分配的代码。

——David Fowler


CoreCLRCoreFX的 GitHub 存储库不断收到大量的拉取请求,都是聚焦于通过减少分配来提高性能。这些努力直接导致了 ASP . NET Core 的诞生。根据Tech Empower的基准测试,.NET Core 已经成为世界上速度最快的 Web 服务器之一。见证这些进步令人难以置信,但它们源于大量时间和精力的付出以及社区的参与。微软是在开放的环境下发展的,这使得开源开发者社区能够为这些创新做出贡献。性能改进不局限于减少分配;通过利用硬件的固有特性,甚至可以获得更底层的收益。


不断发展的 C#

不用说,我是 C#语言的超级粉丝,而 .Net Core 是用 C#构建的并且以性能为中心。所以,我想在这里稍微讨论一下,这可能有点出乎意料。


作为 .Net Core 的一个主题,只要有可能,以性能为重心的新功能不仅应该公开给公众使用,而且应该在内部使用。

——Stephen Toub


C# 7 及其后续的单点版本,以及现在的 C# 8,都触及到了社区采用的容忍界限。我非常信赖语言的进化。我支持这样做,但与此同时,我同情那些因为业务限制而无法采用新版本的开发人员。我能理解这样的担忧;您要问下自己——“价值定位是什么?”某些新特性以性能为中心,您可以根据自己的需要考虑这些特性。


在最近 Twitter 上的一个帖子中,Nick Craver 说:“C# 8对我来说已经死了,”这句话大致的意思是“StackExchange要很多年才能升级到 C# 8。”这部分是因为某些 C#特性依赖于公共语言运行时 CLR 的更新。一个例子是“默认接口成员”特性,它目前依赖于 .NET Core 3.0。绝大多数其他特性只依赖于 C#编译器,这就完美了。


.NET 基金会

鉴于 .NET 术语在 Web 上满天飞,再多告诉您一个也无妨了。


.NET基金会是一个独立的组织,旨在促进围绕.NET 生态系统的开放开发和协作。它为社区和商业开发人员提供了一个论坛,旨在通过促进开放性和社区参与来鼓励创新,从而拓宽和强化 .NET 生态系统的未来。


一定要访问他们的网站并参与其中,或者成为其中的一员。作为成员,你就有资格在董事会投票——同样,你也有资格成为董事会年度选举的候选人。我实际上是 2019 年董事会候选人之一。


我建议你订阅他们的时事通讯,以便可以了解最新消息。


富有意义的发展之路

.NET 生态系统是一个不断变化的生态圈,我相信它正在朝着一个伟大的方向发展。有了开源和跨平台这两个关键优先事项,您就可以放心了。当我意识到 .NET Core 和 .NET Framework 是 .NET 生态系统的压力源,并导致了 .NET 5 的统一时,我个人感到振奋。虽然这几年颇痛苦,但它也使这样的创新成为可能。我建议您尝试移植到 .NET Core,并开始使用 .NET Core 进行任何新的开发;这就是未来。尽管 .NET Standard 的方向尚且未知,但在有进一步的消息之前,我们仍然建议使用它。我希望,无论决定是什么,影响都不会太大。


关于作者

David Pine 是微软的 MVP、谷歌开发专家和内容开发人员。David 喜欢与技术社区共享知识,并在国际会议、用户组和技术会议上发言。David 热衷于通过写作来分享他的想法,并在davidpine.net上积极地维护着一个博客。David 的文章已经发表在 ASP . NET、MSDN Web-Dev、MSDN .NET、Dot NET Curry 和 InfoQ 上。作为回报社区的另一种方式,David 喜欢为开源项目和 StackOverflow.com 做贡献。David 是技术委员会成员,并且是近四年来 Cream City Code 的主要组织者之一。工作之余,他会和他的妻子以及他们的三个儿子 Lyric、Londyn 和 Lennyx 呆在一起。您可以在推特上关注 David(@davidpine7)。


原文链接:


Navigating the .NET Ecosystem


2019 年 9 月 19 日 08:002568
用户头像

发布了 354 篇内容, 共 154.0 次阅读, 收获喜欢 784 次。

关注

评论 2 条评论

发布
用户头像
文章中的链接是怎么回事,乱七八糟的。
2019 年 09 月 19 日 12:08
回复
非常抱歉,已经修改,感谢反馈。
2019 年 09 月 19 日 15:37
回复
没有更多了
发现更多内容

kubernetes ceph-csi分析-目录导航

良凯尔

Kubernetes 源码分析 Ceph CSI

架构实战营模块二总结

竹林七贤

新同学与老司机

小天同学

职场成长 工作体会 经验总结 4月日更 新同学

Play with Go

Rayjun

go 教程

external-provisioner源码分析(2)-main方法与Leader选举分析

良凯尔

Kubernetes 源码分析 Ceph CSI

计算机原理学习笔记 Day7

穿过生命散发芬芳

计算机原理 4月日更

华仔训练营第二次作业

方堃

架构实战营模块二作业

日照时间长

架构实战营

技术实践丨列存表并发更新时的锁等待问题原理

华为云开发者社区

事务 update 元组 列存表

面向对象编程九诫

风翱

面向对象编程 【4 月日更】

2000架无人机火了!文旅景区营销力度加大,户外广告成必选项!

󠀛Ferry

四月日更

LitmusChaos: K8s上的混沌工程框架

混沌工程实践

k8s 混沌工程 litmuschaos 实践框架 故障实验库

数据脱敏:数仓安全隐私保护见真招儿

华为云开发者社区

数据仓库 加密 隐私保护 GaussDB(DWS) 数据脱敏

这才是大数据的正确打开方式

华为云开发者社区

大数据 数据仓库 云原生 数据治理 灾备

k8s通过ceph-csi接入存储的概要分析

良凯尔

Kubernetes 源码分析 Ceph CSI

第十一周总结

external-provisioner源码分析(3)-组件启动参数分析

良凯尔

Kubernetes 源码分析 Ceph CSI

边缘计算是流行词还是风口?开发者怎样选开源项目?

华为云开发者社区

开源 开发者 5G 边缘计算 EdgeGallery 社区

Python-Net编程

若尘

Python 网络编程 net

因为这几个TypeScript代码的坏习惯,同事被罚了500块

华为云开发者社区

typescript 运算符 代码 null strict

安卓rxjava合并多个请求,我的阿里手淘面试经历分享,面试必会

欢喜学安卓

android 程序员 面试 移动开发

安卓内存监控悬浮窗,2021Android面试心得,全套教学资料

欢喜学安卓

android 程序员 面试 移动开发

Golang Map 和字符串

escray

go 极客时间 学习笔记 4月日更 Go 语言从入门到实践x

模块二作业

求索

架构实战营

external-provisioner源码分析(1)-主体处理逻辑分析

良凯尔

Kubernetes 源码分析 Ceph CSI

热乎的6个Notion使用技巧,学不会算我输。

彭宏豪95

效率 Notion 笔记 4月日更

架構實戰營 - 模塊 2 作業

Frank Yang

架构实战营

python 函数详解

若尘

函数编程 函数

Go Functions

escray

go 极客时间 学习笔记 4月日更 Go 语言从入门到实践

重读《重构2》- 封装变量

顿晓

重构 4月日更

基于crudapi增删改查接口后端Java SDK二次开发之环境搭建(一)

crudapi

Java API sdk crud crudapi

.NET生态系统概览-InfoQ