最近在不少自媒體上看到有關(guān).NET與C#的資訊與評價，感覺大家對.NET與C#還是不太了解，尤其是對2016年6月發(fā)布的跨平臺.NET Core 1.0，更是知之甚少。在考慮一番之后，還是決定寫點東西總結(jié)一下，也回顧一下.NET的發(fā)展歷史。

首先，你沒看錯，.NET是跨平臺的，可以在Windows、Linux和MacOS以及它們的各個發(fā)行版上運行，不僅如此，從2022年4月28日開始，.NET開源社區(qū)正式支持國產(chǎn)龍芯芯片龍架構(gòu)（LoongArch），這使得.NET在國家信創(chuàng)這一領(lǐng)域又邁出了一大步。咦？.NET跨平臺這事情我知道呀，為何要特別提起呢？因為真的有很多人不知道，而且不乏各種短視頻平臺里出現(xiàn)的各種技術(shù)專家和技術(shù)大咖，紛紛表示.NET只能在Windows上運行，跨平臺困難，落地和部署困難。

其次，.NET的成功案例有很多，大家都知道，.NET和C#會用在游戲開發(fā)、工控領(lǐng)域、老系統(tǒng)維護等項目和場景中，卻并不了解其實下面這些也都是.NET的成功案例，或者有著.NET的影子：

1. Stackoverflow - 全球最大技術(shù)問答網(wǎng)站

2. Microsoft Azure - 微軟云平臺

3. 博客園 - 就是本站

4. Microsoft Bing - 微軟搜索引擎

5. Office 365

6. Azure DevOps

7. GoDaddy

8. Trello

9. DocuSign

10. Github的部分后端服務(wù) - 說明一下，Github主要是Ruby on Rails實現(xiàn)的，可是還有短視頻博主說Ruby語言快死了

在上面的列表中，有些可能你還不認(rèn)識，剩下的認(rèn)識的大部分都是微軟自己的產(chǎn)品，你會說.NET只有微軟自己用，但不管是誰用，這些站點和應(yīng)用都是超大規(guī)模級別的，說明使用.NET來構(gòu)建超大規(guī)模級別的大型應(yīng)用是完全沒有問題的：容器化、云原生、微服務(wù)、Serverless，.NET都可以勝任；AI時代，ML.NET、Semantic Kernel、LLamaSharp、Cognitive Services等等.NET原生框架和開發(fā)SDK，在微軟Azure OpenAI Services的加持下，為.NET在AI領(lǐng)域發(fā)力提供了更多的機會。

此外，.NET是開源的，.NET的各個部分通過不同的Repository維護在Github上，這些倉儲基本上都是以MIT和Apache 2的許可協(xié)議進行開源，由微軟員工作為主要貢獻者，因此，在開源的同時，又保證了倉儲的持續(xù)更新維護和提交代碼的質(zhì)量。不僅如此，.NET Foundation還收納了不少知名開源項目，這對完善整個.NET生態(tài)起到了非常積極的作用。

那這里的.NET是指.NET Framework嗎？算是，但也不完全是。之前為大家熟知的那個只能在Windows下運行的版本，稱為.NET Framework，自2016年開始，微軟發(fā)布跨平臺版本的.NET框架時，它作為經(jīng)典.NET Framework的跨平臺版本，被稱之為.NET Core，.NET Core延續(xù)到3.1版之后，被改名為.NET 5，然后就是后來的6、7、8、9等各個版本。對于這部分內(nèi)容，我后面會介紹，但我想在介紹更多詳細(xì)信息之前，先簡單地回顧一下.NET的歷史。

.NET極簡史：從Visual J++開始

大家都知道，剛剛退休的Java之父詹姆斯·高斯林曾經(jīng)在1991年就開始參與Java語言的構(gòu)建，然后Sun Microsystems公司于1996年發(fā)布了Java 1.0版本，但很少有人知道，微軟在同年10月份發(fā)布了自己的Java語言：Visual J++。Visual J++開發(fā)的程序基于微軟自研的MSJVM運行，雖然J++遵循Java語言規(guī)范，但微軟并沒有選擇完全根據(jù)Sun公司的Java規(guī)范來設(shè)計自己的JVM，于是，MSJVM實際上并不完全支持Sun Java的所有能力，包括Java RMI和JNI。而另一方面，微軟還在Visual J++中加入了一些自己的設(shè)計，比如通過回調(diào)函數(shù)和委托來實現(xiàn)事件處理，這就使得Visual J++變得更像另一種新的編程語言。不僅如此，Visual J++在訪問系統(tǒng)資源方面，也不遵循Sun Java SDK規(guī)范，而是通過自己定義的J/Direct接口來讓代碼直接訪問操作系統(tǒng)層面的API，于是，Visual J++在某些方面性能要大大優(yōu)于Sun Java（很是懷疑這個J/Direct就是后來的P/Invoke）。從技術(shù)角度，使用了這些特殊功能的J++應(yīng)用程序其實無法在Sun Java JVM上運行，不過當(dāng)時也有不少開源項目，比如Kaffe項目，它們可以使J++應(yīng)用程序無需移植即可直接在這些開源的JVM上運行。但這些開源項目也最終沒有被廣泛應(yīng)用。

一開始的時候，Sun公司愿意在Java語言上與微軟合作，而由于Visual J++里的各種騷功能和騷設(shè)計打破了Sun Java規(guī)范，以至于MSJVM未能通過Sun公司的合規(guī)性測試，于是，在Sun公司的起訴下，微軟逐漸停止了Visual J++的研發(fā)。不過，在這個過程中，微軟積累了豐富的技術(shù)和經(jīng)驗，這些技術(shù)和經(jīng)驗逐漸演化成后來的.NET平臺和Visual J#（一種可以運行在.NET Framework上的Java編程語言，注意：是編程語言，就是用Java的語法寫.NET Framework的應(yīng)用程序）。Visual J#是Visual J++的續(xù)作，目的是能夠讓原來的Visual J++開發(fā)人員可以平滑地遷移到.NET平臺上。

之后就是2002年4月15日發(fā)布的.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系統(tǒng)上。當(dāng)年我正好讀大三，記得數(shù)據(jù)庫這門課的課程設(shè)計，就是用Visual Studio.NET 2002做的。由于操作系統(tǒng)可以是32或者64位的，屬于不同的CPU架構(gòu)，因此，從這個層面也可以說.NET是跨平臺的：在Windows操作系統(tǒng)下跨平臺。說起跨平臺，雖然一開始由于市場策略、技術(shù)實現(xiàn)、開源生態(tài)等等因素，微軟最終選擇讓.NET只在Windows下運行，但同時也力求將各種設(shè)計通過ISO和ECMA進行標(biāo)準(zhǔn)化，這為后續(xù)社區(qū)版跨平臺.NET Framework：Mono Project、Xamarin以及.NET Core的出現(xiàn)，打下了堅實的基礎(chǔ)。

值得一提的是，由于CLI標(biāo)準(zhǔn)化的存在，使得任何編程語言，只要符合相關(guān)規(guī)范，都可以在.NET上運行（這里我就不區(qū)分跨平臺.NET還是經(jīng)典.NET Framework了，單說編程語言這部分內(nèi)容，兩者原理是一樣的），于是，你可能會看到有人使用以下語言來開發(fā).NET應(yīng)用程序：

• Visual C#：不用說，.NET語言中的一等公民，為什么叫C#？因為它比C++多兩個+號，四個+號兩個一行，就拼成了#，足以明微軟之志：C#比C++更發(fā)達(dá)。C#語言由編程大神安德爾斯·海爾斯伯格設(shè)計，不認(rèn)識他？他基于PASCAL語法，編寫了當(dāng)時編譯效率最高的Borland Turbo Pascal編譯器，最終成就了Borland Delphi，他還是Typescript的作者。啥也別說，給賞飯吃的大神三鞠躬

• Visual Basic.NET（VB.NET）：不用說，微軟系編程語言中資歷最老的，比爾蓋茨就是靠BASIC語言起家

• F#：微軟自研函數(shù)式編程語言，國內(nèi)用的不多，國外狂熱分子不少

• C++/CLI：微軟自研托管C++語言，運行在.NET CLR上，它可以直接鏈接原生C++的庫，從而在.NET項目中提供C++的互操作性（interoperability）

• Powershell：微軟自研的跨平臺的自動化配置管理工具/框架，它對于結(jié)構(gòu)化數(shù)據(jù)（比如JSON、XML等）的處理、RESTful API的訪問以及處理對象模型等方面做了很好的優(yōu)化。國內(nèi)應(yīng)用不多，但國外社區(qū)非?；钴S

• IronPython：一個在.NET上運行的Python的開源版本，它可以同時使用Python和.NET的開發(fā)庫，在一些專業(yè)性的產(chǎn)品上有一定應(yīng)用，比如全球領(lǐng)先的BI軟件Spotfire就提供IronPython的運行時（Runtime），并允許IronPython腳本運行在服務(wù)端。IronPython最新更新是在2023年7月

• IronRuby：跟IronPython類似，是Ruby語言的.NET實現(xiàn)，但是在10多年前就已經(jīng)停更了

• Visual J#：已經(jīng)停產(chǎn)，更沒人用了，列在這里主要就是為了說明，即使是Java編程語言，也是可以支持.NET的

• Delphi 8及之后的版本，有對.NET Framework支持的功能

從2002年4月15日到2022年8月9日這20年時間，.NET Framework經(jīng)歷了大大小小17個版本，功能也在不斷的增強，在2016年隨著.NET Standard的引入，從.NET Framework 4.5開始，不同版本的.NET Framework也被歸屬到對應(yīng)版本的.NET Standard之下，而發(fā)布于2019年4月18日的.NET Framework 4.8，也成為了經(jīng)典.NET Framework的最后一個版本（雖然2022年8月9日發(fā)布了.NET Framework 4.8.1，但并不是一個主版本）。

后續(xù)版本的.NET被稱為.NET 5，從版本號上可以看到，.NET 5可以看成是.NET Framework 4.8的延續(xù)，它去掉了“Framework”字樣，以示與之前經(jīng)典.NET Framework的區(qū)別，.NET 5及后續(xù)版本都是跨平臺的，現(xiàn)在回看這段歷史可以發(fā)現(xiàn)，之前的.NET Core 1.0到3.1其實都是.NET跨平臺歷程的中間版本，這些版本存在的價值，就是讓.NET開發(fā)人員和用.NET Framework開發(fā)的項目可以通過這些.NET Core的版本，能夠無縫地、逐步地過渡到跨平臺的、現(xiàn)代化的.NET上。不得不佩服微軟在.NET跨平臺這方面無論在市場戰(zhàn)略上，還是技術(shù)戰(zhàn)術(shù)上，都表現(xiàn)得非常出色。

.NET歷史就介紹這么點，了解這些基本也就夠了，接下來我會逐步從技術(shù)角度，來介紹一些與.NET相關(guān)的新概念。

.NET跨平臺與.NET Standard

可以這樣理解：.NET Standard是.NET跨平臺的基礎(chǔ)。.NET Standard其實就是一套.NET下的API規(guī)范，它的第一個版本與2016年的.NET Core 1.0同時發(fā)布，每一個版本的.NET Standard都規(guī)定了實現(xiàn)這一版本規(guī)范的不同的.NET實現(xiàn)應(yīng)該包含哪些API。更具體些：為了跨Linux、MacOS、Windows、iOS、Android等多個平臺，.NET會針對這些平臺提供不同的實現(xiàn)，這些實現(xiàn)包括：.NET Core、.NET Framework、Xamarin套件（iOS、Mac和Andriod）、用于游戲開發(fā)的Unity下的.NET等等，如果這些實現(xiàn)能夠遵循某個版本的API標(biāo)準(zhǔn)，那么，基于這個版本的API標(biāo)準(zhǔn)所開發(fā)的應(yīng)用程序，就可以運行于這些不同平臺上，而這套API標(biāo)準(zhǔn)就是.NET Standard。另一方面，如果希望開發(fā)出來的類庫和組件能夠被不同平臺的應(yīng)用程序使用，那么，只需要指定這個類庫和組件所基于的.NET Standard版本即可。

然而，最開始的.NET Framework并不能跨平臺，微軟為了逐步實現(xiàn).NET跨平臺這個目標(biāo)，先后發(fā)布了從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下，就會有對應(yīng)版本的.NET實現(xiàn)對其進行支持。比如對于.NET Standard 2.0，經(jīng)典的.NET Framework需要4.6.1及以上的版本才支持.NET Standard 2.0，因為這些版本實現(xiàn)了.NET Standard 2.0中所定義的那32638個API。于是，使用.NET Standard 2.0開發(fā)的類庫，就可以被.NET Framework 4.6.1所引用。

演練：在不同的.NET項目中使用.NET Standard 2.0類庫

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

然后加入一個類：

再新建一個經(jīng)典.NET Framework 4.6.1的Console Application：

然后直接引用前面的ClassLibraryNetStandard20類庫并寫代碼調(diào)用里面的函數(shù)，可以看到，程序可以正常運行：

當(dāng)然，這個ClassLibraryNetStandard20也可以被一個.NET 8的應(yīng)用程序調(diào)用：

打開這個ClassLibraryNetStandard20項目的輸出目錄，可以看到，編譯出來的程序集被放在了Debug\netstandard2.0目錄下：

但是，如果我們新建一個.NET Standard 2.1的Class Library，則無法被.NET Framework 4.6.1的項目引用，此時會報錯：

因為.NET Framework 4.6.1沒有實現(xiàn).NET Standard 2.1，換句話說，.NET Standard 2.1中的有些API在.NET Framework 4.6.1中并沒有實現(xiàn)，那么基于.NET Standard 2.1開發(fā)出來的類庫自然也不能被.NET Framework 4.6.1的項目所引用。經(jīng)典.NET Framework的最后一個版本4.8.1僅實現(xiàn)了.NET Standard 2.0，因此，如果你打算開發(fā)一個既可以被經(jīng)典.NET Framework項目使用，又可以被跨平臺.NET（曾經(jīng)的.NET Core，現(xiàn)在的.NET 5+）項目使用的話，你需要將你的類庫定向（targeting）到.NET Standard 2.0，或者使用多目標(biāo)框架（Multi-targeting）。

在【這個頁面】中，有一張表，展示了.NET Standard各個版本與不同的.NET實現(xiàn)的版本之間的對應(yīng)關(guān)系，可以通過下拉框來選擇不同的.NET Standard版本來查看不同的.NET實現(xiàn)的哪些版本與之對應(yīng)。理論如此，但是在真正實踐的過程中，有些具體的問題是需要特殊處理的。比如：.NET Framework 4.7是支持.NET Standard 2.0的，但是，.NET Framework 4.7發(fā)布于2017年4月，而.NET Standard 2.0則晚于.NET Framework 4.7發(fā)布（2017年8月），那么如何讓一個已經(jīng)發(fā)布的.NET Framework版本支持新的.NET Standard呢？解決方案就是使用NuGet Package，將.NET Framework中未實現(xiàn)的.NET Standard API以NuGet Package的形式引入，從而彌補這個差異。因此你會發(fā)現(xiàn)，對于.NET Framework 4.7.1及其以前版本的.NET項目，如果需要引用一個由.NET Standard 2.0實現(xiàn)的類庫的話，就需要額外引用NETStandard.Library這個Meta Package，這個Meta Package中包含了不同版本.NET項目所需依賴的Assembly的版本信息。另外，Visual Studio在處理這個事情上也有差異：

• Visual Studio 2017 15.3之前的版本需要在IDE中顯式引用這個Meta Package

• 從Visual Studio 2017 15.3開始，不再需要在IDE中顯式引用這個Meta Package，也就是說，在新建的.NET Framework 4.7.1及以前版本的項目上引用.NET Standard 2.0，不再需要額外去引用NETStandard.Library，Visual Studio會自動幫你完成這個工作。當(dāng)然，這并不表示你的項目就不需要NETStandard.Library了，只是在IDE的操作上比以前更加簡單了

在編譯出來的結(jié)果上也存在差異，下面左圖是一個.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已經(jīng)自帶了這些DLL了：

多目標(biāo)框架（Multi-targeting）

盡管.NET Standard提供了不同.NET實現(xiàn)（.NET Framework、.NET Core和Xamarin等）之間統(tǒng)一的API規(guī)范，但在有些場景下，仍然希望能夠充分利用不同平臺的特性和性能優(yōu)化，或者需要支持特定平臺的功能，此時僅將項目定向到.NET Standard已經(jīng)不能滿足需求。對于這種場景，.NET允許開發(fā)面向多目標(biāo)框架的類庫，一方面可以通過條件編譯指令來使用特定平臺的API，另一方面也可以為類庫的調(diào)用方提供不同平臺的支持。

比如，在C#項目文件（.csproj文件）中，使用下面的方式，讓類庫同時支持.NET Standard 2.1項目和.NET Framework 4.8的項目：

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFrameworks>netstandard2.1;net4.8</TargetFrameworks>
    <Nullable>enable</Nullable>
    <LangVersion>8.0</LangVersion>
  </PropertyGroup>
</Project>

注意上面的TargetFrameworks標(biāo)記，在這個XML標(biāo)記下，列出了該類庫所支持的.NET Standard/.NET Framework的版本，它在編譯之后，會產(chǎn)生兩個輸出文件夾，其中包含了支持不同版本.NET的程序集：

另一個需要注意的地方是，在上面的csproj文件定義中，指定了所使用的C#版本為8.0，這是因為“可空引用類型”（Nullable Reference Types）是在C# 8.0中引入的，而如果將代碼同時定向到.NET Framework 4.8，那么就無法支持可空引用類型，因為.NET Framework 4.8所支持的最高的C#版本為C# 7.3。有關(guān).NET與C#版本之間的關(guān)系，后文我會介紹。

一個使用“多目標(biāo)框架”的非常著名的開源框架就是log4net。log4net是一個古老的.NET下的日志輸出工具，它一開始是log4j的.NET移植版本，所以，老版本的log4net使用了很多經(jīng)典.NET Framework特有的API，比如System.Configuration命名空間下的基于XML的框架配置代碼。隨著.NET Core和跨平臺.NET的發(fā)布，log4net也逐步提供了對.NET Standard 1.3和.NET Standard 2.0的支持，所以，現(xiàn)在的.NET 5/6/7/8項目都可以直接引用log4net用作日志輸出。在log4net的官方代碼庫中，可以學(xué)習(xí)到它是如何實現(xiàn)多目標(biāo)框架的。

事實上從.NET 5開始，.NET真正實現(xiàn)了跨平臺，.NET Standard也基本完成了它的使命，但.NET Standard并不會退出歷史舞臺，微軟會繼續(xù)對其進行維護。

至此，與.NET跨平臺和.NET Standard相關(guān)的內(nèi)容就差不多介紹完了，當(dāng)然還有部分細(xì)節(jié)和一些歷史遺留問題的處理方式相關(guān)內(nèi)容（比如Portable Class Library，PCLs），這里就不再贅述了，否則篇幅太長，hold不住啊。接下來我們聊聊C#和.NET Framework之間的關(guān)系吧。

C#語言特性與.NET Framework

如果你是C#語言的初學(xué)者，那么你一定會產(chǎn)生一個疑問：int和System.Int32有什么區(qū)別？在C#中到底是使用int，還是用System.Int32？其實，C#中的int等價于System.Int32，也就是說，你既可以使用int這個C#關(guān)鍵字來定義一個32位有符號整數(shù)類型的變量，也可以使用System.Int32這個.NET類型來定義一個32位有符號整數(shù)類型的變量。官方文檔上說int是System.Int32的別名，但也可以理解為，int是C#能夠支持32位有符號整數(shù)類型的語言特性。

由此可以得出一個結(jié)論：C#的語言特性是需要.NET Framework（或者.NET）支持的（有些高級的語言特性甚至需要不同版本的.NET CLR支持），但兩者的版本之間也不一定需要有嚴(yán)格的對應(yīng)關(guān)系。C#語言特性本質(zhì)上是通過C#編譯器實現(xiàn)的，只要編譯輸出的MSIL代碼能夠在.NET Framework（或者.NET）上運行起來，那么這些語言特性就可以被該版本的.NET Framework所支持。下面請看一個具體的案例。

演練：在.NET Framework 4.6.1的項目中使用C# 9.0的新特性

現(xiàn)在我們嘗試在一個.NET Framework 4.6.1（發(fā)布于2015年11月）的項目中，使用C# 9.0（發(fā)布于2020年11月）的新特性。首先新建一個.NET Framework 4.6.1的Console Application：

然后，修改csproj文件，將C#語言版本升級到C# 9.0：

然后，使用C# 9.0中“關(guān)系型模式匹配”新特性編寫一段代碼：

然后直接運行，可以看到，程序是可以正常編譯執(zhí)行的：

那么，是不是所有的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。之后就可以正常編譯運行代碼了：

請注意：經(jīng)典.NET Framework最高支持到C# 7.3，C# 8.0是專門面向.NET Core的第一個主要C#版本，它的一些新功能依賴于新的Core CLR的相關(guān)功能?！?a target="_blank" rel="noopener" style="margin: 0px; padding: 0px; color: rgb(71, 124, 209); text-decoration-line: none;">這篇官方文檔】詳細(xì)列舉了C#語言的發(fā)展歷史以及各個版本的新功能，下面這張表格列舉了不同.NET版本下，創(chuàng)建新項目時所使用的默認(rèn)的C#語言版本（參考官方文檔）：

轉(zhuǎn)自https://www.cnblogs.com/daxnet/p/18299758  作者dax.net