揭秘.NET Core剪裁器背後的技術
十天前，我發布了對.NET Core程式進行瘦身的開源軟體Zack.DotNetTrimmer，與.NET Core內置的剪裁器相比，Zack.DotNetTrimmer不僅對程式的剪裁效果更好，而且還支援WPF、WinForm程式。
很多朋友對於這個開源項目的原理很感興趣，因此我將通過這篇文章為大家介紹它的工作原理。
技術1、檢測程式載入的程式集和類
微軟提供了用於對.NET Core的運行時行為進行分析的庫Diagnostics，它可以獲取豐富的運行時資訊，比如類的實例創建、程式集載入、類載入、方法調用、GC運行、文件讀寫操作、網路連接等。Visual Studio中對每個方法的調用時間進行評估的工具就是使用Diagnostics實現的。
要使用Diagnostics庫，我們首先需要安裝Microsoft.Diagnostics.NETCore.Client和Microsoft.Diagnostics.Tracing.TraceEvent這兩個程式集，然後使用DiagnosticsClient類來連接被分析的.NET Core程式的進程。程式碼如下所示：
using Microsoft.Diagnostics.NETCore.Client;
using Microsoft.Diagnostics.Tracing;
using Microsoft.Diagnostics.Tracing.Parsers;
using Microsoft.Diagnostics.Tracing.Parsers.Clr;
using System.Diagnostics;
using System.Diagnostics.Tracing;
string filepath = @"E:\temp\test6\ConsoleApp1.exe";//被分析的程式路徑
ProcessStartInfo psInfo = new ProcessStartInfo(filepath);
psInfo.UseShellExecute = true;
using Process? p = Process.Start(psInfo);//啟動程式
var providers = new List<EventPipeProvider>()//要監聽的事件
{
new EventPipeProvider("Microsoft-Windows-DotNETRuntime",
EventLevel.Informational, (long)ClrTraceEventParser.Keywords.All)
};
var client = new DiagnosticsClient(p.Id);//設定DiagnosticsClient監聽的進程
using EventPipeSession session = client.StartEventPipeSession(providers, false);//啟動監聽
var source = new EventPipeEventSource(session.EventStream);
source.Clr.All += (TraceEvent obj) =>
{
if (obj is ModuleLoadUnloadTraceData)//程式集載入事件
{
var data = (ModuleLoadUnloadTraceData)obj;
string path = data.ModuleILPath;//獲取程式集的路徑
Console.WriteLine($"Assembly Loaded:{path}");
}
else if (obj is TypeLoadStopTraceData)//類載入事件
{
var data = (TypeLoadStopTraceData)obj;
string typeName = data.TypeName;//獲取類名
Console.WriteLine($"Type Loaded:{typeName}");
}
};
source.Process();
不同類型的消息對應source.Clr.All事件中的不同類型的對象，這些類都繼承自TraceEvent，我這裡分析的是程式集載入事件ModuleLoadUnloadTraceData和類載入事件TypeLoadStopTraceData。
這樣我們就可以得知程式運行過程中載入的程式集和類型資訊，這樣就知道哪些程式集和類型沒有被載入，從而我們就知道要刪除哪些程式集和類型了。
技術2、刪除程式集中用不到的類
Zack.DotNetTrimmer中提供了可以刪除程式集中用不到的類的IL的功能，這個功能使用dnlib這個庫來完成的程式集文件的編輯。Dnlib是一個對.NET程式集文件進行讀、寫、編輯的開源項目。
在Dnlib中，我們使用ModuleDefMD.Load來載入一個現有的程式集，Load方法的返回值是ModuleDefMD類型。ModuleDefMD代表程式集資訊，比如其中的Types屬性就代表程式集中的所有的類型。我們可以對ModuleDefMD以及其中的對象進行修改後，把修改完成的程式集調用Write方法再保存到磁碟中。
比如，下面的程式碼用來把一個程式集中的所有非public類型都給改成public類型，並且把方法上修飾的Attribute全部清除：
using dnlib.DotNet;
string filename = @"E:\temp\net6.0\AppToBeTested1.dll";
ModuleDefMD module = ModuleDefMD.Load(filename);
foreach(var typeDef in module.Types)
{
if (typeDef.IsPublic == false)
{
typeDef.Attributes |= TypeAttributes.Public;//修改類的訪問級別
}
foreach(var methodDef in typeDef.Methods)
{
methodDef.CustomAttributes.Clear();//清除方法的Attribute
}
}
module.Write(@"E:\temp\net6.0\1.dll");//保存修改
下面是待測試的程式集的源程式碼：
internal class Class1
{
[DisplayName("AAA")]
public void AA()
{
Console.WriteLine("hello");
}
}
如下是修改後的程式集的反編譯結果：
public class Class1
{
public void AA()
{
Console.WriteLine("hello");
}
}
可以看到我們對於程式集的修改起作用了。
掌握了使用Dnlib對程式集進行修改的方法，我們就可以實現刪除程式集中用不到的類型的功能了，我們只要把對應的類型從ModuleDefMD的Types屬性中刪除掉即可。不過在實際操作中，這樣做會遇到問題，因為我們要刪除的類可能被其他的地方引用，儘管那些地方只是引用我們要刪除的類，並沒有真的調用，但是為了保證修改後程式集的校驗合法性，ModuleDefMD的Write方法仍然會做合法性校驗，否則Write方法就會拋出ModuleWriterException異常，比如：
ModuleWriterException: 'A method was removed that is still referenced by this module.'
因此，我們編寫程式碼需要對程式集做仔細的檢查，確保刪除每一個引用要被刪除的類的地方。因為類定義本身佔用的文件尺寸很少，主要的程式碼的空間佔用都在類的方法體中，因此我找了一個替代方案，那就是並不刪除類，只是把類的方法體清空。
Dnlib中，方法對應的類型是MethodDef類型，MethodDef的CilBody 類型的Body屬性代表方法的方法體。如果方法擁有方法體（也就是不是抽象方法等），那麼CilBody的Instructions就代表方法體程式碼的IL指令的集合。因此我立即想到了通過下面的程式碼來清空方法的方法體：
methodDef.Body.Instructions.Clear();
但是在運行的時候，使用上面的程式碼清理後的ModuleDefMD進行保存的時候，可能會引起程式集結構非法的問題，比如有的方法定義了返回值，如果我們直接清空方法體，就會造成方法沒有返回值被返回的問題。因此我換了一種思路，也就是把所有的方法體都改成throw null;這個C#程式碼對應的IL程式碼，因為所有的方法體都是可以改成拋出一個異常的形式來保證邏輯的正確性。因此我編寫如下的程式碼來進行方法體的清理：
method.Body.ExceptionHandlers.Clear();
method.Body.Instructions.Clear();
method.Body.Variables.Clear();
method.Body.Instructions.Add(new Instruction(OpCodes.Nop) { Offset = 0 });
method.Body.Instructions.Add(new Instruction(OpCodes.Ldnull) { Offset = 1 });
method.Body.Instructions.Add(new Instruction(OpCodes.Throw) { Offset = 2 });
最後三行添加的IL程式碼就是對應throw null這行C#程式碼。
請查看項目的github地址獲取全部源程式碼，項目地址：//github.com/yangzhongke/Zack.DotNetTrimmer
Dnlib使用的其他問題
在使用Dnlib過程中，我還有一些其他的收穫，在這裡記錄下來與大家分享。
收穫一、Dnlib保存含有本地程式碼的程式集時候遇到的問題
在使用上面我提到的方法清理程式集的時候，對於我們編寫的自定義程式集以及第三方NuGet包的程式集的時候，大部分是沒問題的。但是在使用同樣的方法處理PresentationCore.dll、System.Private.CoreLib.dll等.NET Core基礎程式集的時候遇到了問題，那就是即使我對程式集只是Load之後，不做任何的改動後，直接Write，程式集也會發生明顯的變小。比如我用下面的程式碼處理一下PresentationFramework.dll：
using (var mod = ModuleDefMD.Load(@"E:\temp\PresentationFramework.dll"))
{
mod.Write(@"E:\temp\PresentationFramework.New.dll");
}
原始的PresentationFramework.dll大小是15.9MB，而保存後新的文件大小只有5.7MB。經過詢問Dnlib作者得知，這些程式集含有本地程式碼（比如使用C++/CLI編寫的程式碼或者ReadyToRun / NGEN / CrossGen等格式的程式集），使用Write方法保存的時候會忽略這些本地程式碼，這就是保存後的程式集尺寸明顯變小的原因。我們可以使用NativeWrite方法代替Write方法，因為這個方法會保留本地程式碼。
不過，根據AsmResolver（一個和DnLib類似的開源項目）的作者Washi1337所說，NativeWrite方法會盡量保存本地程式碼的結構因此無法減小程式集的尺寸，甚至有可能反而增大程式集的尺寸（詳見//github.com/Washi1337/AsmResolver/issues/267）。而且在實際使用的時候，我發現對於這些程式集進行修改之後，程式就會啟動失敗，查看Windows事件日誌，我發現是程式啟動的時候CLR啟動失敗造成的。根據Washi1337所說，如果只是程式集中含有ReadyToRun的本地程式碼，那麼只要去掉程式集中的ILLibrary標誌，讓CLR跳過ReadyToRun本地程式碼，而直接執行IL程式碼就行了，畢竟對於ReadyToRun優化後的程式集仍然保存了原始的IL程式碼。但是我如Washi1337所說的操作之後，程式依舊啟動失敗，不清楚是什麼原因，因為含有本地程式碼的程式集無法被很好的剪裁，因此我沒有再深入研究，歡迎對CLR精通的朋友分享經驗。
收穫二、Dnlib的其他應用
由於DnLib可以修改程式集，因此我們可以使用它做很多的事情，比如修改程式的默認行為（你懂的）。我們可以使用DnLib編寫一個自己的程式碼混淆器或者實現面向切面編程（AOP）的靜態織入。
你還想到了哪些DnLib的應用場景？歡迎分享。
