ToB企服应用市场:ToB评测及商务社交产业平台

标题: .NET科普：.NET简史、.NET Standard以及C#和.NET Framework之间的关系 [打印本页]
作者: 忿忿的泥巴坨    时间: 2024-7-18 00:51
标题: .NET科普：.NET简史、.NET Standard以及C#和.NET Framework之间的关系
近来在不少自媒体上看到有关.NET与C#的资讯与评价，感觉各人对.NET与C#还是不太相识，尤其是对2016年6月发布的跨平台.NET Core 1.0，更是知之甚少。在考虑一番之后，还是决定写点东西总结一下，也回顾一下.NET的发展汗青。
起首，你没看错，.NET是跨平台的，可以在Windows、Linux和MacOS以及它们的各个发行版上运行，不仅如此，从2022年4月28日开始，.NET开源社区正式支持国产龙芯芯片龙架构（LoongArch），这使得.NET在国家书创这一领域又迈出了一大步。咦？.NET跨平台这事情我知道呀，为何要特别提起呢？由于真的有很多人不知道，而且不乏各种短视频平台里出现的各种技术专家和技术大咖，纷纷表现.NET只能在Windows上运行，跨平台困难，落地和部署困难。
其次，.NET的成功案例有很多，各人都知道，.NET和C#会用在游戏开发、工控领域、老系统维护等项目和场景中，却并不相识其实下面这些也都是.NET的成功案例，或者有着.NET的影子：
在上面的列表中，有些可能你还不熟悉，剩下的熟悉的大部分都是微软自己的产物，你会说.NET只有微软自己用，但不管是谁用，这些站点和应用都是超大规模级别的，阐明使用.NET来构建超大规模级别的大型应用是完全没有题目标：容器化、云原生、微服务、Serverless，.NET都可以胜任；AI时代，ML.NET、Semantic Kernel、LLamaSharp、Cognitive Services等等.NET原生框架和开发SDK，在微软Azure OpenAI Services的加持下，为.NET在AI领域发力提供了更多的机会。
此外，.NET是开源的，.NET的各个部分通过差别的Repository维护在Github上，这些仓储基本上都是以MIT和Apache 2的许可协议进行开源，由微软员工作为紧张贡献者，因此，在开源的同时，又保证了仓储的持续更新维护和提交接码的质量。不仅如此，.NET Foundation还收纳了不少知名开源项目，这对完善整个.NET生态起到了非常积极的作用。
那这里的.NET是指.NET Framework吗？算是，但也不完全是。之前为各人熟知的谁人只能在Windows下运行的版本，称为.NET Framework，自2016年开始，微软发布跨平台版本的.NET框架时，它作为经典.NET Framework的跨平台版本，被称之为.NET Core，.NET Core延续到3.1版之后，被改名为.NET 5，然后就是后来的6、7、8、9等各个版本。对于这部分内容，我后面会介绍，但我想在介绍更多具体信息之前，先简朴地回顾一下.NET的汗青。
.NET极简史：从Visual J++开始

各人都知道，刚刚退休的Java之父詹姆斯·高斯林曾经在1991年就开始参与Java语言的构建，然后Sun Microsystems公司于1996年发布了Java 1.0版本，但很少有人知道，微软在同年10月份发布了自己的Java语言：Visual J++。Visual J++开发的程序基于微软自研的MSJVM运行，虽然J++遵照Java语言规范，但微软并没有选择完全根据Sun公司的Java规范来计划自己的JVM，于是，MSJVM实际上并不完全支持Sun Java的所有能力，包括Java RMI和JNI。而另一方面，微软还在Visual J++中加入了一些自己的计划，比如通过回调函数和委托来实现事件处置惩罚，这就使得Visual J++变得更像另一种新的编程语言。不仅如此，Visual J++在访问系统资源方面，也不遵照Sun Java SDK规范，而是通过自己定义的J/Direct接口来让代码直接访问操作系统层面的API，于是，Visual J++在某些方面性能要大大优于Sun Java（很是怀疑这个J/Direct就是后来的P/Invoke）。从技术角度，使用了这些特殊功能的J++应用程序其实无法在Sun Java JVM上运行，不过当时也有不少开源项目，比如Kaffe项目，它们可以使J++应用程序无需移植即可直接在这些开源的JVM上运行。但这些开源项目也最终没有被广泛应用。
一开始的时候，Sun公司乐意在Java语言上与微软合作，而由于Visual J++里的各种骚功能和骚计划打破了Sun Java规范，以至于MSJVM未能通过Sun公司的合规性测试，于是，在Sun公司的告状下，微软逐渐停止了Visual J++的研发。不过，在这个过程中，微软积累了丰富的技术和经验，这些技术和经验逐渐演化成后来的.NET平台和Visual J#（一种可以运行在.NET Framework上的Java编程语言，留意：是编程语言，就是用Java的语法写.NET Framework的应用程序）。Visual J#是Visual J++的续作，目标是可以或许让原来的Visual J++开发职员可以平滑地迁移到.NET平台上。
之后就是2002年4月15日发布的.NET Framework 1.0和Visual Studio.NET 2002（留意是Visual Studio.NET，不是Visual Studio，从Visual Studio 2005开始，名字里去掉了.NET字样），它可以安装并运行在Windows NT 4.0 SP6、Windows 98、Windows 98 SE、Windows ME、Windows 2000和Windows XP系统上。当年我恰好读大三，记得数据库这门课的课程计划，就是用Visual Studio.NET 2002做的。由于操作系统可以是32或者64位的，属于差别的CPU架构，因此，从这个层面也可以说.NET是跨平台的：在Windows操作系统下跨平台。说起跨平台，虽然一开始由于市场战略、技术实现、开源生态等等因素，微软最终选择让.NET只在Windows下运行，但同时也力求将各种计划通过ISO和ECMA进行标准化，这为后续社区版跨平台.NET Framework：Mono Project、Xamarin以及.NET Core的出现，打下了坚实的根本。
值得一提的是，由于CLI标准化的存在，使得任何编程语言，只要符合相关规范，都可以在.NET上运行（这里我就不区分跨平台.NET还是经典.NET Framework了，单说编程语言这部分内容，两者原理是一样的），于是，你可能会看到有人使用以下语言来开发.NET应用程序：
从2002年4月15日到2022年8月9日这20年时间，.NET Framework履历了大大小小17个版本，功能也在不断的加强，在2016年随着.NET Standard的引入，从.NET Framework 4.5开始，差别版本的.NET Framework也被归属到对应版本的.NET Standard之下，而发布于2019年4月18日的.NET Framework 4.8，也成为了经典.NET Framework的末了一个版本（虽然2022年8月9日发布了.NET Framework 4.8.1，但并不是一个主版本）。
后续版本的.NET被称为.NET 5，从版本号上可以看到，.NET 5可以当作是.NET Framework 4.8的延续，它去掉了“Framework”字样，以示与之前经典.NET Framework的区别，.NET 5及后续版本都是跨平台的，现在回看这段汗青可以发现，之前的.NET Core 1.0到3.1其实都是.NET跨平台进程的中间版本，这些版本存在的价值，就是让.NET开发职员和用.NET Framework开发的项目可以通过这些.NET Core的版本，可以或许无缝地、逐步地过渡到跨平台的、现代化的.NET上。不得不佩服微软在.NET跨平台这方面无论在市场战略上，还是技术战术上，都表现得非常精彩。
.NET汗青就介绍这么点，相识这些基本也就够了，接下来我会逐步从技术角度，来介绍一些与.NET相关的新概念。
.NET跨平台与.NET Standard

可以这样理解：.NET Standard是.NET跨平台的根本。.NET Standard其实就是一套.NET下的API规范，它的第一个版本与2016年的.NET Core 1.0同时发布，每一个版本的.NET Standard都规定了实现这一版本规范的差别的.NET实现应该包含哪些API。更具体些：为了跨Linux、MacOS、Windows、iOS、Android等多个平台，.NET会针对这些平台提供差别的实现，这些实现包括：.NET Core、.NET Framework、Xamarin套件（iOS、Mac和Andriod）、用于游戏开发的Unity下的.NET等等，假如这些实现可以或许遵照某个版本的API标准，那么，基于这个版本的API标准所开发的应用程序，就可以运行于这些差别平台上，而这套API标准就是.NET Standard。另一方面，假如希望开发出来的类库和组件可以或许被差别平台的应用程序使用，那么，只需要指定这个类库和组件所基于的.NET Standard版本即可。
然而，最开始的.NET Framework并不能跨平台，微软为了逐步实现.NET跨平台这个目标，先后发布了从1.0到2.1一共9个版本的.NET Standard，每个.NET Standard版本下，都增加一部分.NET API的支持，比如，.NET Standard 1.0仅支持37118个API中的7949个，.NET Standard 2.0支持37118个API中的32638个，而最新的.NET Standard 2.1则支持所有37118个API。因此，在差别版本的.NET Standard下，就会有对应版本的.NET实现对其进行支持。比如对于.NET Standard 2.0，经典的.NET Framework需要4.6.1及以上的版本才支持.NET Standard 2.0，由于这些版本实现了.NET Standard 2.0中所定义的那32638个API。于是，使用.NET Standard 2.0开发的类库，就可以被.NET Framework 4.6.1所引用。
演练：在差别的.NET项目中使用.NET Standard 2.0类库

在Visual Studio 2022中，新建一个.NET Standard 2.0的Class Library：

然后加入一个类：

再新建一个经典.NET Framework 4.6.1的Console Application：

然后直接引用前面的ClassLibraryNetStandard20类库并写代码调用内里的函数，可以看到，程序可以正常运行：

当然，这个ClassLibraryNetStandard20也可以被一个.NET 8的应用程序调用：

打开这个ClassLibraryNetStandard20项目标输出目录，可以看到，编译出来的程序集被放在了Debug\netstandard2.0目录下：

但是，假如我们新建一个.NET Standard 2.1的Class Library，则无法被.NET Framework 4.6.1的项目引用，此时会报错：

由于.NET Framework 4.6.1没有实现.NET Standard 2.1，换句话说，.NET Standard 2.1中的有些API在.NET Framework 4.6.1中并没有实现，那么基于.NET Standard 2.1开发出来的类库天然也不能被.NET Framework 4.6.1的项目所引用。经典.NET Framework的末了一个版本4.8.1仅实现了.NET Standard 2.0，因此，假如你计划开发一个既可以被经典.NET Framework项目使用，又可以被跨平台.NET（曾经的.NET Core，现在的.NET 5+）项目使用的话，你需要将你的类库定向（targeting）到.NET Standard 2.0，或者使用多目标框架（Multi-targeting）。
在【这个页面】中，有一张表，展示了.NET Standard各个版本与差别的.NET实现的版本之间的对应关系，可以通过下拉框来选择差别的.NET Standard版原来检察差别的.NET实现的哪些版本与之对应。理论如此，但是在真正实践的过程中，有些具体的题目是需要特殊处置惩罚的。比如：.NET Framework 4.7是支持.NET Standard 2.0的，但是，.NET Framework 4.7发布于2017年4月，而.NET Standard 2.0则晚于.NET Framework 4.7发布（2017年8月），那么如何让一个已经发布的.NET Framework版本支持新的.NET Standard呢？解决方案就是使用NuGet Package，将.NET Framework中未实现的.NET Standard API以NuGet Package的形式引入，从而弥补这个差异。因此你会发现，对于.NET Framework 4.7.1及其以前版本的.NET项目，假如需要引用一个由.NET Standard 2.0实现的类库的话，就需要额外引用NETStandard.Library这个Meta Package，这个Meta Package中包含了差别版本.NET项目所需依靠的Assembly的版本信息。另外，Visual Studio在处置惩罚这个事情上也有差异：
在编译出来的效果上也存在差异，下面左图是一个.NET Framework 4.7的项目引用了一个.NET Standard 2.0的项目后的编译输出，右图是.NET Framework 4.8.1的项目引用了.NET Standard 2.0项目后的编译输出，可以看到，4.7的项目编译后，会在编译路径下天生一堆System DLL，外加一个netstandard.dll，而4.8.1的项目编译天生路径下就非常干净，由于.NET Framework 4.8.1已经自带了这些DLL了：

多目标框架（Multi-targeting）

尽管.NET Standard提供了差别.NET实现（.NET Framework、.NET Core和Xamarin等）之间统一的API规范，但在有些场景下，仍然希望可以或许充分使用差别平台的特性和性能优化，或者需要支持特定平台的功能，此时仅将项目定向到.NET Standard已经不能满足需求。对于这种场景，.NET允许开发面向多目标框架的类库，一方面可以通过条件编译指令来使用特定平台的API，另一方面也可以为类库的调用方提供差别平台的支持。
比如，在C#项目文件（.csproj文件）中，使用下面的方式，让类库同时支持.NET Standard 2.1项目和.NET Framework 4.8的项目：
  1. <Project Sdk="Microsoft.NET.Sdk">
  3.   <PropertyGroup>
  4.     <TargetFrameworks>netstandard2.1;net4.8</TargetFrameworks>
  5.     <Nullable>enable</Nullable>
  6.     <LangVersion>8.0</LangVersion>
  7.   </PropertyGroup>
  9. </Project>
复制代码
留意上面的TargetFrameworks标记，在这个XML标记下，列出了该类库所支持的.NET Standard/.NET Framework的版本，它在编译之后，会产生两个输出文件夹，其中包含了支持差别版本.NET的程序集：

另一个需要留意的地方是，在上面的csproj文件定义中，指定了所使用的C#版本为8.0，这是由于“可空引用类型”（Nullable Reference Types）是在C# 8.0中引入的，而假如将代码同时定向到.NET Framework 4.8，那么就无法支持可空引用类型，由于.NET Framework 4.8所支持的最高的C#版本为C# 7.3。有关.NET与C#版本之间的关系，后文我会介绍。
一个使用“多目标框架”的非常著名的开源框架就是log4net。log4net是一个古老的.NET下的日志输出工具，它一开始是log4j的.NET移植版本，所以，老版本的log4net使用了很多经典.NET Framework特有的API，比如System.Configuration定名空间下的基于XML的框架配置代码。随着.NET Core和跨平台.NET的发布，log4net也逐步提供了对.NET Standard 1.3和.NET Standard 2.0的支持，所以，现在的.NET 5/6/7/8项目都可以直接引用log4net用作日志输出。在log4net的官方代码库中，可以学习到它是如何实现多目标框架的。
事实上从.NET 5开始，.NET真正实现了跨平台，.NET Standard也基本完成了它的使命，但.NET Standard并不会退出汗青舞台，微软会继续对其进行维护。
至此，与.NET跨平台和.NET Standard相关的内容就差不多介绍完了，当然另有部分细节和一些汗青遗留题目标处置惩罚方式相关内容（比如Portable Class Library，PCLs），这里就不再赘述了，否则篇幅太长，hold不住啊。接下来我们聊聊C#和.NET Framework之间的关系吧。
C#语言特性与.NET Framework

假如你是C#语言的初学者，那么你一定会产生一个疑问：int和System.Int32有什么区别？在C#中到底是使用int，还是用System.Int32？其实，C#中的int等价于System.Int32，也就是说，你既可以使用int这个C#关键字来定义一个32位有符号整数类型的变量，也可以使用System.Int32这个.NET类型来定义一个32位有符号整数类型的变量。官方文档上说int是System.Int32的别名，但也可以理解为，int是C#可以或许支持32位有符号整数类型的语言特性。
由此可以得出一个结论：C#的语言特性是需要.NET Framework（或者.NET）支持的（有些高级的语言特性甚至需要差别版本的.NET CLR支持），但两者的版本之间也不一定需要有严格的对应关系。C#语言特性本质上是通过C#编译器实现的，只要编译输出的MSIL代码可以或许在.NET Framework（或者.NET）上运行起来，那么这些语言特性就可以被该版本的.NET Framework所支持。下面请看一个具体的案例。
演练：在.NET Framework 4.6.1的项目中使用C# 9.0的新特性

现在我们尝试在一个.NET Framework 4.6.1（发布于2015年11月）的项目中，使用C# 9.0（发布于2020年11月）的新特性。起首新建一个.NET Framework 4.6.1的Console Application：

然后，修改csproj文件，将C#语言版本升级到C# 9.0：

然后，使用C# 9.0中“关系型模式匹配”新特性编写一段代码：

然后直接运行，可以看到，程序是可以正常编译执行的：

那么，是不是所有的C# 9.0的新特性，都可以在.NET Framework 4.6.1中使用呢？答案是否定的，就要看C# 9.0的编译器是否可以天生可以或许被该版本.NET Framework所支持的代码，或者说，C#编译器所天生的代码中依靠的那些类型，是否在该版本的.NET Framework下支持。举个例子，同样是C# 9.0的新特性，仅限Init的资源库新特性则无法直接在一个.NET Framework 4.6.1的项目中使用，编译器提示：Predefined type 'System.Runtime.CompilerServices.IsExternalInit' is not defined or imported：

缘故原由是，C# 9.0编译器在编译带有这个新语法特性的代码时，需要检查.NET下是否包含IsExternalInit类型，假如该类型存在，则允许使用该语法特性，而该类型在.NET Framework 4.6.1中不存在。因此，解决这个题目，既可以自己在项目中写一个空的IsExternalInit类型，或者引用一个第三方的IsExternalInit NuGet Package。之后就可以正常编译运行代码了：

请留意：经典.NET Framework最高支持到C# 7.3，C# 8.0是专门面向.NET Core的第一个紧张C#版本，它的一些新功能依靠于新的Core CLR的相关功能。【这篇官方文档】具体枚举了C#语言的发展汗青以及各个版本的新功能，下面这张表格枚举了差别.NET版本下，创建新项目时所使用的默认的C#语言版本（参考官方文档）：

总结

本文先从介绍.NET汗青开始，引出跨平台的相关话题，进而介绍了.NET Standard、Multi-targeting以及C#版本与.NET Framework之间的关系，文章所引用的外部文档全都以超链接的形式嵌在文章之中，就不额外逐个列出。这些都不是最新内容，只是尽可能地做个总结，希望可以或许帮到平常需要的朋友，同时也对.NET相关的概念和知识扫扫盲，让更多的朋友相识.NET和C#这一优秀的框架和编程语言。

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。



欢迎光临 ToB企服应用市场:ToB评测及商务社交产业平台 (https://dis.qidao123.com/) Powered by Discuz! X3.4