昨天我知道 Build 最重要的成果，就是：

MiniWebFramework.dll

我知道它很重要，卻不知道裡面到底放了什麼。

今天我終於決定把它拆開。

我原本以為打開後應該會看到：

Console.WriteLine("Day4");

或者至少還能看到一些熟悉的 C# 程式碼。

但是真正看到的內容，完全出乎我的意料。

Compiler 到底把我的 C# 變成了什麼？

以前我一直認為Compiler 只是把副檔名從：

.cs 變成 .dll

所以DLL 裡面應該還是：

Console.WriteLine("Day4");

最多只是加密一點或者它已經直接變成CPU 能執行的機器碼。

今天我要來親自驗證。

今天我沒有使用第三方工具而是使用 Microsoft 提供的：

ILDasm

接著我開啟：

MiniWebFramework.dll

第一眼看到的是：

MANIFEST

Program

和我原本預期的Program.cs完全不同。

這代表：Compiler 並沒有把我的原始碼直接放進 DLL，它已經變成另一種形式了。

接著。

我點開：

Program

↓

<Main>$()

真正看到的內容。

是：

-IL_0000: ldstr "Day4"

-IL_0005: call System.Console::WriteLine

-IL_000b: ret

那一瞬間我知道DLL 裡面放的不是：

Console.WriteLine("Day4");

而是另一種我從來沒看過的語言。

雖然我還不懂 IL，但我試著猜猜看

第一行：

ldstr "Day4"

很像：

Load String

第二行：

call

看起來是在呼叫：

Console.WriteLine()

最後：

ret

應該代表方法結束我沒有急著查每一個指令。

因為今天真正重要的不是學會 IL。

而是知道：

Compiler 並沒有把 C# 直接交給 CPU。

查閱 Microsoft 官方文件後，我確認 DLL 中保存的是 CIL（Common Intermediate Language），也常稱為 IL（Intermediate Language）。它是一種與 CPU 無關的中介語言，並不是 C# 原始碼，也不是機器碼。

也就是說，C# 編譯器的工作，是把 C# 編譯成 IL，之後再由 .NET 執行階段於執行時進一步處理。

昨天的我：

Compiler 把 C# 編譯好。

今天的我：

Compiler 並不是把 C# 直接變成 CPU 可以執行的機器碼，而是先變成 IL。

今天我第一次真正看到：

Compiler 的作品。

不是：

Console.WriteLine("Day4");

而是：

ldstr

call

ret

這就是：

Compiler 留下的成果。

以前我一直以為 Compiler 很神秘。

今天我第一次真正看到它交出的成果。

那一刻我才理解，Compiler 並不是把程式「變不見」。

而是把我熟悉的 C#，翻譯成另一種 .NET 能理解的語言。

這也是 C# 到 CPU 之間，最重要的一座橋梁。

與 Mini Web Framework 的關聯
今天我研究的不是範例程式，而是自己建立的 MiniWebFramework 專案。

雖然目前它只有一行 Console.WriteLine("Day4");，但透過 ILDasm，我已經能看到它在編譯後變成的 IL。

未來當我加入 Router、Middleware、HttpContext 等功能時，它們也會先被編譯成 IL，再交由 .NET 執行階段處理。

理解這一點，代表我開始理解自己的 Framework 真正是如何一步步被執行的。

今天我知道了 DLL 裡裝的是 IL。

但是新的問題又出現了CPU 看不懂 C#。

今天也知道CPU 同樣看不懂 IL。

那麼IL 最後到底是怎麼變成 CPU 可以執行的機器碼？

下一篇，我們就要認識整個 .NET 執行流程中最後一位關鍵角色：

JIT（Just-In-Time Compiler）。