.NET5.0 單檔案釋出打包操作深度剖析
前言
隨著 .NET5.0 Preview 8 的釋出，許多新功能正在被社群成員一一探索；這其中就包含了“單檔案釋出”這個炫酷的功能，實際上，這也是社群一直以來的呼聲，從 WinForm 的 msi 開始，我們就希望有這樣一個功能，雖然在 docker 時代，單檔案釋出的功能顯得“不那麼重要”，但正是從這一點可以看出，.NET 的團隊成員一直在致力於實用功能的完善。
在 Java 的世界裡，單檔案釋出一直伴隨著他們的成長，War 檔案可以直接上傳到 Tomcat 上執行，話說我們還是有那麼一丟丟的羨慕的，不過凡事有利就有弊，單檔案釋出對於細分模組的熱更新來說，還有有一點點的不方便。
不過瑕不掩瑜，在微服務概念越來越火熱的今天，相信單檔案釋出的功能帶給大家更多的是興奮。
什麼是單檔案釋出
首先，我們要清楚的瞭解，什麼是單檔案釋出。
官方的目標定義：
.Net 5.0單個檔案解決方案應為：
- 廣泛相容：可以將包含IL程式集，隨時執行的程式集，複合程式集，本機二進位制檔案，配置檔案等的應用程式打包為一個可執行檔案。
- 可以直接從打包軟體直接執行應用程式的託管元件，而無需提取到磁碟。
- 可與偵錯程式和工具一起使用。
從上面的目標可以看出，和以往版本最大的不同在於：將所有依賴打包到一個可執行檔案中，可直接執行，不影響除錯操作。
注意上面的這句話“將所有依賴打包到一個可執行檔案中”，而在以往，我們使用 dotnet publish 將應用程式進行釋出之後，我們會看到，在 publish 下有許多專案依賴的 dll 檔案，在 .NET5.0 到來之後，這些依賴檔案可收納到一個檔案中，瞬間讓人感受到了清涼。
釋出操作指令相關
命令
| 平臺 | 命令 | 說明 |
|---|---|---|
| Linux | dotnet publish -r linux-x64 /p:PublishSingleFile=true | - |
| Windows | dotnet publish -r win-x64 --self-contained=false /p:PublishSingleFile=true | - |
| Mac OS | - | - |
可選引數
| 屬性 | 描述 |
|---|---|
| IncludeNativeLibrariesInSingleFile | 在釋出時，將依賴的本機二進位制檔案打包到單檔案應用程式中。 |
| IncludeSymbolsInSingleFile | 將 .pdb 檔案打包到單個檔案中。提供該選項是為了和 .NET 3 單檔案模式相容。建議替代的方法是生成帶有嵌入式的 PDB （ |
| IncludeAllContentInSingleFile | 將所有釋出的檔案（符號檔案除外）打包到單檔案中。該選項提供是為了向後相容 .NETCore 3.x 版本 |
配置檔案設定引數
除了可以使用命令列引數的形式，還可以通過配置檔案的形式設定釋出引數，編輯專案檔案，新增配置節點到檔案中並儲存即可。
<PropertyGroup>
<TargetFramework>net5.0</TargetFramework>
<RuntimeIdentifier>linux-x64</RuntimeIdentifier>
<PublishSingleFile>true</PublishSingleFile>
<IncludeContentInSingleFile>true</IncludeContentInSingleFile>
</PropertyGroup>
關於 RID 說明見：https://docs.microsoft.com/en-us/dotnet/core/rid-catalog
這是截止本文釋出前的 RID 版本，不排除 .NET5.0 有新的釋出
其它引數
除了上面的三個可選引數，我在查詢文件的過程中還發現，官方還提到了其它引數的使用，目前不確定是否有效
<PropertyGroup>
<SelfContained>true</SelfContained>
<!--啟用使用assemby修剪-僅支援自包含應用程式-->
<PublishTrimmed> true </PublishTrimmed>
<!--啟用AOT編譯 目前暫不支援預編譯-->
<!--<PublishReadyToRun>true</PublishReadyToRun>-->
</PropertyGroup>
<ItemGroup>
<Content Update="*-exclute.dll">
<CopyToPublishDirectory>PreserveNewest</CopyToPublishDirectory>
<ExcludeFromSingleFile>true</ExcludeFromSingleFile>
</Content>
</ItemGroup>
還可以通過設定 ExcludeFromSingleFile 元素，該設定將指定某些檔案不嵌入單個檔案之中。
編寫待打包的應用程式
為了更直觀的看出正常釋出和單檔案釋出的區別，我們特別準備了一個 Web 應用程式，並對兩個程式集進行依賴引用。
準備好專案，編譯成功，嘗試釋出，開啟 PowerShel 控制檯，分別輸入以下命令
dotnet publish -r linux-x64 /p:PublishSingleFile=true
dotnet publish -r win-x64 --self-contained=false /p:PublishSingleFile=true
linux-x64 和 win-x64 兩個目錄下，分別有 publish 目錄，由於平臺的不同，所引用的依賴也不一樣，這是我們早就瞭解過的，我們看看打包前後的區別
以上執行的兩條命令語句，會為我們生成 Linux 和 Windows 兩個平臺的程式包，從上圖中可以看出，在打包之前，專案的各種引用依賴都被複制到了釋出目錄下，這也是我們之前的程式釋出方式，在經過打包後，所有依賴檔案都被裝入了一個可執行檔案中，在 Linux 平臺下表現為：PreviewWebApplication ，Windows 平臺下則為：PreviewWebApplication.exe。從打包效果來看，遷移將變得更加方便了。
執行打包程式
打包後的程式和未打包的釋出程式在執行方式上沒有太多的差異性，在 Windows 平臺上，只需要雙擊 PreviewWebApplication.exe 就可以執行該打包程式了，本示例建立的是一個 WebApi 的程式，直接訪問程式偵聽的地址後得到介面返回的結果，如果您建立的是帶有 Razor 檢視或者攜帶其它資原始檔的，可能無法訪問指定的 url。
在程式成功執行起來後，我們發現，打包程式並沒有解壓縮檔案到磁碟，而是直接從包中載入檔案到記憶體中執行；這是巨大的進步，也是和 War 檔案根本的區別。
需要注意的是，該 .exe 檔案並不能單獨複製到別的地方執行，你必須把 .exe 當前目錄完整的複製才能執行，這涉及到主機探測的問題，下面我們將會一一提到。
跨平臺的打包檔案
通過上面的示例我們瞭解到，打包程式總是為不同的平臺生成獨立的包程式，這是為什麼呢？這裡就涉及到一個概念，也就是 Tool Interface Standard (TIS)
Executable and Linking Format(ELF)
Common Object File Format（COFF）於1983年引入，最初使用在 AT&T 的 UNIX 系統上。由於 COFF 的各種侷限性，比如：節的最大數量受到限制，節名稱，所包含的原始檔的長度受到限制，並且符號除錯資訊無法支援實際的語言。最後，在 System V Release 4 (SVR4) 釋出後，AT&T 使用 ELF 替代了 COFF。
工具介面標準委員會
援引委員會規範檔案的說明：可執行檔案和連結格式最初由 UNIX 系統開發和釋出實驗室（USL）作為應用程式二進位制介面（API）的一部分。工具介面標準委員會 （TIS） 選擇將不斷髮展的 ELF 標準作為行動式物件檔案。該標準適用於各種作業系統的 32 位英特爾架構環境的格式。ELF 標準旨在通過向開發人員提供具有一組跨多個操作環境的二進位制介面定義。這將減少不同介面實現的數量，從而減少需要重新編寫和編譯的程式碼。
ELF 檔案結構又分為三種型別，分別是：
| 名稱 | 說明 | 描述 |
|---|---|---|
| 可重定位檔案 | Relocatable File | 包含適合與其他物件檔案連結的程式碼和資料，以建立可執行檔案或共享物件檔案。 |
| 可執行檔案 | Executable File | 包含適合執行的程式 |
| 共享目標檔案 | Shared Object File | 包含適合在兩種上下文中連結的程式碼和資料。首先，連結編輯器可以處理它與其他可重新刪除和共享的物件檔案，以建立另一個物件檔案。其次，動態連結器將其與可執行檔案和其他共享物件相結合，以建立程式映像。 |
Portable Executable (PE)
在 Windows 陣營，微軟在此 COFF 標準的基礎上，又進行了創新和發展出了 PE 檔案標準
PE Format
該規範描述了Windows作業系統家族下的可執行檔案（影像）和目標檔案的結構。這些檔案分別稱為可移植可執行（PE）和公用物件檔案格式（COFF）檔案。
從上面的兩種規範中可以看出，LinuX 和 Windows 都有各自的檔案格式規範，而這種規範在一定程度上是不相容的，不論是從檔案結構還是解析方式；所以 .NET5.0 中的打包程式必須為不同的平臺實現獨立的打包器。打包器的實現在 runtime 中的 Microsoft.NET.HostModel 庫中。
認識了 ELF 和 PE 檔案結構之後，我們就可以對打包器程式碼進行閱讀理解。
Microsoft.NET.HostModel
你可以從 github 上下載 .NET 5.0 的原始碼，
轉到目錄：
runtime/src/installer/managed/Microsoft.NET.HostModel
原始碼不太多，可直接進行閱讀，主要理解層次關係即可。
打包器主要包含了三大部分的內容，分別是 AppHost、Boundler、ComHost
| 模組 | 說明 |
|---|---|
| AppHost | 用於單檔案主機啟動時的檔案探測，還複製將程式資源從 App.dll 複製到 AppHost備用，目前已通過 HostFxr 和 HostPolicy 進行靜態連結，其探測邏輯已轉移到 HostPolicy（由C++編寫） |
| Boundler | 打包器的具體實現，主要是將應用程式及其依賴項嵌入 AppHost 中，隨後釋出單個可執行檔案到指定目錄 |
| ComHost | 建立一個包含嵌入式 CLSIDMap 檔案的 ComHost，以將 CLSID 對映到 .NET 類。 |
在檔案 Boundle/Manifest.cs 的頭部，我們看到了“單檔案程式”的檔案結構定義
BundleManifest is a description of the contents of a bundle file.
This class handles creation and consumption of bundle-manifests.
Here is the description of the Bundle Layout:
_______________________________________________
AppHost
------------Embedded Files ---------------------
The embedded files including the app, its
configuration files, dependencies, and
possibly the runtime.
------------ Bundle Header -------------
MajorVersion
MinorVersion
NumEmbeddedFiles
ExtractionID
DepsJson Location [Version 2+]
Offset
Size
RuntimeConfigJson Location [Version 2+]
Offset
Size
Flags [Version 2+]
- - - - - - Manifest Entries - - - - - - - - - - -
Series of FileEntries (for each embedded file)
[File Type, Name, Offset, Size information]
_________________________________________________
從上面的檔案結構中，我們可以非常清晰的看到，單檔案程式的結構一共分為三大部分，分別是：
| 定義 | 說明 | 描述 |
|---|---|---|
| 嵌入的檔案 | Embedded file | 主要是配置檔案和描述檔案，比如 .deps.json,runtimeconfig.json 等檔案 |
| 打包檔案頭資訊 | Bundle Header | 描述了整個檔案的結構資訊，型別，儲存位置，段、表等資訊 |
| 實體清單 | Manifest Entries | 實際打包的檔案列表，每個檔案分段寫入，可執行檔案使用 16byte - prev file end position 進行分隔，普通檔案直接按 prev file end position 進行寫入 |
檔案頭資訊的檢視
我們可以通過一些工具去檢視已經打包好的檔案，在 Linux 下，可以使用 readelf/objdump 等程式來獲取 PreviewWebApplication 檔案的資訊。在 Windows 下，可以使用 PE Tools 等工具
Linux 下 readelf 讀取檔案頭資訊
從圖中我們可以看到 Type:DYN (Shared object file) 這是一個標準的共享物件檔案，關於 ELF 頭部資訊的內容不再展開，有興趣的同學可以自行學習相關內容。
Windows下 PE Tools 讀取檔案頭資訊
已經打包好的程式內部包含了 319（Linux）、Windows（359） 個檔案，Windows 版本在未打包前是 84.3MB，打包後是 69.8MB，最重要的是在執行時無需解壓縮，直接從 Boundle 中執行檔案。
檔案中的第三部分，也就是 “實體清單（Manifest Entries）的寫入程式碼在 Boundle\Boundler.cs\AddToBundle
long AddToBundle(Stream bundle, Stream file, FileType type)
{
if (type == FileType.Assembly)
{
long misalignment = (bundle.Position % AssemblyAlignment);
if (misalignment != 0)
{
long padding = AssemblyAlignment - misalignment;
bundle.Position += padding;
}
}
file.Position = 0;
long startOffset = bundle.Position;
file.CopyTo(bundle);
return startOffset;
}
在成員方法 GenerateBundle(IReadOnlyList
// 程式碼片段
public string GenerateBundle(IReadOnlyList<FileSpec> fileSpecs)
{
...
foreach (var fileSpec in fileSpecs)
{
string relativePath = fileSpec.BundleRelativePath;
...
using (FileStream file = File.OpenRead(fileSpec.SourcePath))
{
FileType targetType = Target.TargetSpecificFileType(type);
long startOffset = AddToBundle(bundle, file, targetType);
FileEntry entry = BundleManifest.AddEntry(targetType, relativePath, startOffset, file.Length);
Tracer.Log($"Embed: {entry}");
}
}
// Write the bundle manifest
headerOffset = BundleManifest.Write(writer);
...
}
因為解壓器的實現已經轉移到了 HostFxr 和 HostPolicy 中，以靜態連結庫的方式連結到打包器中，且該部分程式碼由 C++ 進行編寫，鑑於 C++ 水平有限，在這裡不作介紹。
結束語
編寫這篇文章耗費了我大量的時間，期間大量閱讀海量的參考資料、文獻、標準文件、製作文章配圖等等，寫乾貨文章真的需要投入巨大的精力和時間，希望你們喜歡。
文章進行到這裡，我知道肯定還有很多同學沒看過癮，但是我們可以通過回顧打包器的開發進度表來體驗一下 .NET 團隊的開發熱情。
主要參考資料
.NET團隊計劃經理 Richard Lander 的部落格：https://devblogs.microsoft.com/dotnet/announcing-net-5-0-preview-8/
Boundler 進度表：https://github.com/dotnet/runtime/issues/36590
single-file：https://github.com/dotnet/designs/tree/master/accepted/2020/single-file
ELF文件：https://refspecs.linuxbase.org/elf/elf.pdf
ELF維基百科：https://en.wikipedia.org/wiki/Executable_and_Linkable_Format
Readelf：https://sourceware.org/binutils/docs/binutils/readelf.html
PE文件：https://docs.microsoft.com/en-us/windows/win32/debug/pe-format
PE Tools：https://github.com/petoolse/petools