.NET Standard 2.0

先前 [1] 分別從 framework 與 virtual machine 兩個面向聊過 .NET framework 的角色，其中提及 Common Language Infrastructure (CLI) 的三大組成：Common Intermediate Language (CIL), standard libraries (BCL and FCL), 與 Common Language Runtime (CLR)。

最近因為 .NET Core 2.0 的正式發佈，越來越多人開始回頭看原本 .NET framework 的組成，以及各種實作與標準之間的關係；這兩天剛好看了 InfoQ 上的一篇文章 [2]；再繼續之前，首先要抓準一個概念：現行的 .NET 平台實作不只 .NET framework 一家，還有 .NET Core, Mono, Xamarin 等等，而各家實作在跨平台的特性與實現方法上也不盡相同，根本原因在於一開始的 CLI standard library 以大鍋菜的方式設計，雖然有 BCL 與 FCL 之分，但 BCL 並未很好地把 Windows dependent 的功能剝離出去，導致後續跨平台 runtime 實作困難。

以下是順手整理的心得：

• .NET Standard 重新定義了 BCL 的標準，讓各家 (.NET Framework, Xamarin, and .NET Core) 實作的 BCL 趨於一致。

• 針對 BCL 之上的 application models，.NET Core 捨棄 Windows Forms 與 Windows Presentation Foundation (WPF)，僅保留 Console，並實作 APS.NET Core [3]。

簡單來說，.NET Standard 是未來跨平台元件或應用程式開發時的必要 (但非充要) 條件，畢竟一個可以正常運作於 .NET Standard 實作上的元件，仍可能依賴該實作的特定函式庫。

至於 Portable Class Libraries (PCL) 則是針對既有 .NET 平台實作所提的暫時方案；透過 Visual Studio 與 PCL 的幫助，Visual Studio 可自動將程式中 dependency 對應到各家實作的函式，免去開發人員額外偵測與判斷的痛苦。有關 PCL，個人認為 InfoQ 文章中參照的 [4] 寫得比較完整。

附帶一提：當微軟在 2017/8/13 發佈 .NET Standard 文件 [5] 時，裡頭的對應表可能讓人誤以為 .NET framework 4.6.1 就已經實作 .NET Standard 2.0；實際上，在 .NET framework 4.6.1 尚須加裝 .NET Core 2.0 SDK 才能支援，否則會缺少 200 多個 API 實作。因此真正的完整支援要到 .NET framework 4.7.1 才算完成 [7]。

see also:
[1] .NET: Framework or Virtual Machine
[2] InfoQ: .NET Core and .NET Standard: What Is the Difference?
[3] .NET Standard - Demystifying .NET Core and .NET Standard
[4] Understanding .NET Core, .NET Standard, .NET Core applications and ASP.NET Core
[5] Microsoft Docs: .NET Standard
[6] Microsoft .NET Blog: Announcing the .NET Framework 4.7.1

.NET: Framework or Virtual Machine

一般提到 .NET 多半使用 .NET framewrok 這個名詞，內容可能包括：

• Programming Languages: 包括 C#, C++/CLI, F#, IronLisp, IronPython, VB.NET, Powershell 等 [1]。
• Compiler
• CLI Standard Library: 裡頭主要有 Framework Class Library (FCL) [2] 與 Base Class Library (BCL) [3]
• Common Intermediate Language (CIL)
• Common Language Runtime (CLR)

對於傳統使用 C++ 搭配 MFC 開發視窗程式 (GUI desktop application) 的開發者而言，視線會集中在 C# 與 CLI Standard Library；此時 .NET 更趨近於 framework 的角色，提供眾多的 classes，開發人員根據 framework 規範撰寫 component。

然而就 .NET 整體架構來看，最大的改變在於提供了統一的 intermediate language (IL) 介面，使得前端可以同時支援多種程式語言，呼叫同一套 standard library；且這個 IL 設計是獨立於 CPU architecture 與 operating system platform 之外的 [4]。換言之，開發者可以自由地在任何想要的平台上開發 IL 所需的 runtime，因此角色上更接近 virtual machine。

雖然說大多數的 .NET 應用程式都在 Windows 與其內建的 runtime，但還是有不少開發者作過這方面的努力：

• DotGNU Protable .NET [5] [6]
• Mono [7]

但實際使用上，卻不那麼順利。主因在於 .NET 雖然 CIL 提供了優良的隔離，獨立於 Windows 之外，但最重要的 CLI Standard Library 卻因為服務視窗程式開發者的初衷，納入了太多 Windows 特有的 library，尤其是圖形介面 (GDI) 這段，導致許多在 Windows 上開發的元件，無法順利過渡到其它 runtime 執行。

換言之，雖然 CIL 與 CLR 提供了很大 virtual machine 的特點，但身為 runtime infrastructure 重點的 standard library 並未提供相應的設計，導致整個 .NET 回到近乎 Windows 獨有的情況。

這幾年微軟開始改革 Windows Server 的產品線 [8]，將圖形介面剝離出來，打破原本 Windows runtime 包山包海的狀況，同時也開始推更乾淨的 .NET Core；就架構而言這應該有助於第三方 .NET runtime 的普及，但微軟將發展 Mono 的 Xamarin 收入麾下卻讓非微軟勢力瞬間消失。

注意：Mono 在 runtime 實作仍是按照舊有的 CLI (ECMA-335) [9] 而非 CoreCLI，因此 Mono 是否會如 .NET Core 壯大仍有很大變數。

此外，Mono 的貢獻在不僅僅於 runtime，還有跨桌面平台的解決方案，這塊的未來應該屬於 Electron [10]；至於依賴 Mono runtime 的跨行動平台方案 - Xamarin，個人認為疑慮就很大，目前 Windows Phone 已確定式微，微軟還願意花多少資源給跨行動平台開發方案，看來非常不樂觀。

這兩年微軟也開始引入 LLVM 技術，實作相關的 compiler (LLILC)，想要深入這個主題的可以一起參考看看。

see also:
[1] Wikipedia: CLI Languages
[2] Wikipedia: Framework Class Library (FCL)
[3] Wikipedia: Standard Libraries (CLI) 
[4] Wikipedia: Common Intermediate Language (CIL)
[5] Wikipedia: DotGNU
[6] Wikipedia: Protable.NET
[7] Mono Project
[8] Wikipedia: Microsoft Windows Server Core
[9] ECMA-335: Common Language Infrastructure (CLI)
[10] Electron