最近在不少自媒體上看到有關.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的影子：
- Stackoverflow - 全球最大技術問答網站
- Microsoft Azure - 微軟雲平臺
- 部落格園 - 就是本站
- Microsoft Bing - 微軟搜尋引擎
- Office 365
- Azure DevOps
- GoDaddy
- Trello
- DocuSign
- Github的部分後端服務 - 說明一下，Github主要是Ruby on Rails實現的，可是還有短影片博主說Ruby語言快死了
在上面的列表中，有些可能你還不認識，剩下的認識的大部分都是微軟自己的產品，你會說.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應用程式：
- Visual C#：不用說，.NET語言中的一等公民，為什麼叫C#？因為它比C++多兩個+號，四個+號兩個一行，就拼成了#，足以明微軟之志：C#比C++更發達。C#語言由程式設計大神安德爾斯·海爾斯伯格設計，不認識他？他基於PASCAL語法，編寫了當時編譯效率最高的Borland Turbo Pascal編譯器，最終成就了Borland Delphi，他還是Typescript的作者。啥也別說，給賞飯吃的大神三鞠躬
- Visual Basic.NET（VB.NET）：不用說，微軟系程式語言中資歷最老的，比爾蓋茲就是靠BASIC語言起家
- F#：微軟自研函數語言程式設計語言，國內用的不多，國外狂熱分子不少
- C++/CLI：微軟自研託管C++語言，執行在.NET CLR上，它可以直接連結原生C++的庫，從而在.NET專案中提供C++的互操作性（interoperability）
- Powershell：微軟自研的跨平臺的自動化配置管理工具/框架，它對於結構化資料（比如JSON、XML等）的處理、RESTful API的訪問以及處理物件模型等方面做了很好的最佳化。國內應用不多，但國外社群非常活躍
- IronPython：一個在.NET上執行的Python的開源版本，它可以同時使用Python和.NET的開發庫，在一些專業性的產品上有一定應用，比如全球領先的BI軟體Spotfire就提供IronPython的執行時（Runtime），並允許IronPython指令碼執行在服務端。IronPython最新更新是在2023年7月
- IronRuby：跟IronPython類似，是Ruby語言的.NET實現，但是在10多年前就已經停更了
- Visual J#：已經停產，更沒人用了，列在這裡主要就是為了說明，即使是Java程式語言，也是可以支援.NET的
- Delphi 8及之後的版本，有對.NET Framework支援的功能
從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在處理這個事情上也有差異：
- 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會自動幫你完成這個工作。當然，這並不表示你的專案就不需要NETStandard.Library了，只是在IDE的操作上比以前更加簡單了
在編譯出來的結果上也存在差異，下面左圖是一個.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的專案：
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFrameworks>netstandard2.1;net4.8</TargetFrameworks>
<Nullable>enable</Nullable>
<LangVersion>8.0</LangVersion>
</PropertyGroup>
</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#這一優秀的框架和程式語言。