.NET

.NET (3.1版以前稱作.NET Core)是微軟開發的第一個跨平臺 (Windows、Mac OSX、Linux）的應用程式開發框架，未來也將會支援FreeBSD與Alpine 平臺。.Net Core也是微軟在一開始發展時就開源的軟體平臺，它經常也會拿來和現有的開源 .NET 平臺Mono比較。由於 .NET Core 的開發目標是跨平臺的 .NET 平臺，因此 .NET Core 會包含 .NET Framework 的類別庫，但與 .NET Framework 不同的是 .NET Core 採用套件化 (Packages) 的管理方式，應用程式只需要取得需要的元件即可，與 .NET Framework 大包式安裝的作法截然不同，同時各套件亦有獨立的版本線 (Version line)，不再硬性要求應用程式跟隨主線版本。.NET Core 專案的主要目標有 ：歷史..NET Core 1.0 於 2016 年 6 月 27 日釋出。2020 年 11 月，微軟釋出了 .NET 5.0，統一了.NET的各個平臺的碎片版本： .NET Framework 4.8, .NET Standard, .NET Core 3.1, Mono, Xamarin等。2021 年 11 月，微軟釋出了 .NET 6.0 。2022 年 11 月，微軟釋出了 .NET 7.0 。核心功能..NET Core 是由許多專案所組成，除了基本的類別庫 (Core FX) 之外，也包含採用 RyuJIT 編譯的執行平臺 Core CLR、編譯器平臺 .NET Compiler Platform、採用 AOT 編譯技術執行最佳化的套件 Core RT (.NET Core Runtime)，以及跨平臺的 MSIL 編譯器 LLILC (LLVM-based MSIL Compiler) 等專案。同時，微軟也發展了一個建置技術檔案的平臺 docfx ，並運用於 .NET Core 的檔案網站。RyuJIT.RyuJIT 是微軟發展的新式即地編譯器 (Just-in-Time Compiler)，用以取代現有的 .NET Framework 的 JIT 以及 JIT64 即地編譯器，依據微軟公佈的測試報告，RyuJIT 的效能較前一代的 JIT 提升約 25%，並支援 SIMD (Single Instruction, Multiple Data) 的技術。RyuJIT 同時應用於 .NET Framework 4.6 以及 .NET Core。Core CLR.Core CLR 移植 .NET Framework 的 CLR 的功能，包含核心程式庫 mscorlib、JIT 編譯器、垃圾收集器 (GC) 以及其他執行 MSIL 所需要的執行期環境。Core RT.Core RT 是以 為主的核心功能，在 .NET Core 內稱為 Core RT，在 UWP 則是稱為 .NET Native。Core RT 會在建造時期 (非執行期) 在編譯時將 MSIL 轉換成平臺原生的機器碼，以獲取較短的啟動時間 (JIT 採用的是執行時期編譯，使得啟動時間拉長)，以及記憶體用量減少的優點。Core RT 會在不同的平臺使用不同的 AOT 技術：LLILC.LLILC (LLVM-based MSIL Compiler，英文發音為 "lilac") 是 .NET Core 在非 Windows 平臺的 MSIL 編譯器，基於 ECMA-335 (Common Language Infrastructure) 的標準將 MSIL 編譯成原生碼執行，適用於可執行 LLVM 的作業系統，例如 Mac OSX 與 Linux 作業系統。LLILC 同時支援 JIT (內含 RyuJIT 的實作) 以及 AOT (未來將開始支援) 的編譯方式。Roslyn..NET Compiler Platform (專案程式碼為 Roslyn) 是將 .NET 平臺的編譯架構標準化的平臺，它可提供程式管理工具 (如整合開發環境) 相當多的情報，用以發展有助於編寫程式與管理程式結構所需要的功能，例如型別資訊、語法結構、參考連結、語意、編譯器、自動化、錯誤回報等等功能，只要是遵循 CLI 標準的程式語言，都可以利用 .NET Compiler Platform 實作出編譯器，讓程式管理工具能實作如語法提示、語法自動完成、關鍵字高亮等視覺化能力。.NET Compiler Platform 可同時支援 .NET Framework 4.6 以上版本，.NET Core 也原生支援。套件管理..NET Core v1.0 時期..NET Core 的類別庫採用 NuGet 套件化的架構，應用程式只需要使用 project.json 的 dependencies 區段加入指定套件版本的參考，就能獲得該套件的功能，與以往 .NET Framework 大包式的提供方法完全不同。.NET Core 團隊宣佈已經有 98% 的 .NET Framework 主要類別庫移轉到 .NET Core 平臺。例如下列 project.json 內容，可直接加入 .NET Standard Library (v1.0.0-rc2-23901) 的參考。"version": "1.0.0-*","compilationOptions": {"emitEntryPoint": true"dependencies": {"NETStandard.Library": "1.0.0-rc2-23901""frameworks": {"netstandardapp1.5": {"imports": "dnxcore50".NET Standard Library 是一個總括型的 NuGet Package，其內包含了這些類別庫套件：其中的 NETStandard.Platform 也是一個總括型套件，包含了下列類別庫套件：開發人員只需要使用 NETStandard.Library 就能加入所有必要的 .NET Core 類別庫參考，但若不需要這麼多元件，也可以只加入特定的套件即可，不一定都要加入 NETStandard.Library。.NET Core v1.1 時期.對於微軟來說，.NET Core 1.0 (以及早期開發時) 使用 project.json 來處理套件管理與版本相依的問題，是因為很多工具還沒趕上 (例如微軟主力的建置工具 MSBuild)，再加上 project.json/xproj 架構並不相容於以 MSBuild 為主的工具鏈 (Toolchain)，若是要修改成相容 project.json/xproj 架構的話可能會付出極大成本，因此在 .NET Core 1.0 RC2 發布不久，官方就宣佈要將 project.json/xproj 系統移回到以 MSBuild 為主的 csproj ，例如下列 csproj 的例子即可看到套件參考的內容。由於 .NET Core 移回了 MSBuild 架構，因此在 Visual Studio 2017 的 .NET Core 工具內，已恢復可直接於 IDE 的 GUI 介面中編修套件參考的功能。應用程式型別..NET Core 基於跨平臺能力，並沒有將與 GUI 高度相關的 API 移植到 .NET Core 內，因此像是 Windows Forms 或是 Windows Presentation Foundation (WPF) 並未移植到 .NET Core。.NET Core 支援主控臺應用程式 (Console Application) 以及類別庫 (Class Library) 型別的專案。不過微軟在其 Universal Windows Platform (UWP) 開發平臺使用了 .NET Core，並且利用 .NET Native 技術將其效能提升至十分接近原生碼的速度。ASP.NET Core 則以主控臺應用程式驅動其代管環境 Kestrel Server 以支援 ASP.NET Core 程式的執行。.NET CLI..NET CLI (Command-Line Interface) 指令列工具是 .NET Core 處理建造、執行與編輯工作的主要工具 ，有幾個主要的動作：與其他平臺的關係..NET Core 經常會拿來與其他平臺做類比，尤其是它的源頭 .NET Framework 以及另一個相似性質的開源平臺 Mono。.NET Framework.據微軟的說明，.NET Core 和 .NET Framework 是子集 (Subset) 與超集 (Superset) 的關係，.NET Core 將會實作出部份的 .NET Framework 功能 (基本上是不含使用者介面的部份)，例如 JIT (.NET Core 採用 RyuJIT)、垃圾收集器 (GC) 以及型別 (包含基本型別以及泛型型別等)。未來 .NET Framework 和 .NET Core 也將會是各自發展，但它們也會同時使用彼此的功能，例如 .NET Compiler Platform 與 RyuJIT 等技術。Mono.Mono 是另一個已發展許久的 .NET Framework 跨平臺開源版本，基本上並不隸屬微軟官方，而是由社群的力量所主導，自成一個生態系統，也開發出了像Xamarin這樣的跨平臺.NET行動應用，.NET Core 與 Mono 未來會是合作的關係，Mono 仍會維持社群力量的維護與發展，而 .NET Core 則會以官方角度來進行發展，兩邊也會一起進行彼此功能上的增進。與 ASP.NET Core 的關係..NET Core 與 ASP.NET Core 的關係其實一開始並不是主從關係 ，ASP.NET Core 的開發初期 (ASP.NET 5) .NET Core 還沒有開始起跑，因此 ASP.NET Core 當時有自己的執行期與工具，一開始稱為 Project K，後來改為 DNX (.NET Execution Environment)，DNX 本身就具有可獨立運作的執行能力，不需要依賴 .NET Core 執行，但是這樣會變成 .NET Core 和 ASP.NET Core 雙頭馬車的現象，在 .NET Core 逐漸成熟之後，微軟也決定要將這兩個各自獨立發展的產品線整合在一起，DNX 也將因改用 .NET Core 執行期而終止開發，DNX 的功能將由 .NET Core 以及旗下的 .NET CLI 接替提供，整合後的版本將在 1.0 RC2 時釋出。支援作業系統..NET 7 支援下列作業系統 ：