揭秘.NET Core剪裁器背后的技术

不久前，我发布了对.NET Core程序进行瘦身的开源软件Zack.DotNetTrimmer，与.NET Core内置的剪裁器相比，Zack.DotNetTrimmer不仅对程序的剪裁效果更好，而且还支持WPF、WinForm程序。

很多朋友对于这个开源项目的原理很感兴趣，因此我将通过这篇文章为大家介绍它的工作原理。

微软MVP实验室研究员
 

杨中科
微软MVP（最有价值专家），IT技术传播者，全网30万粉丝，编写了《零基础趣学C语言》《自己动手写开发工具》《J2EE开发全程实录》等图书，编写的《ASP.NET Core 内幕与项目实战》即将于2022年五月份出版。

技术1-检测程序加载的程序集和类
 

微软提供了用于对.NETCore的运行时行为进行分析的库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;
usingMicrosoft.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 = newProcessStartInfo(filepath);
psInfo.UseShellExecute = true;
using Process? p = Process.Start(psInfo);//启动程序
var providers = newList<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 = newEventPipeEventSource(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")]
       publicvoid AA()
       {
              Console.WriteLine("hello");
       }
}

如下是修改后的程序集的反编译结果：

public class Class1
{
       publicvoid AA()
       {
              Console.WriteLine("hello");
       }
}

可以看到我们对于程序集的修改起作用了。

掌握了使用Dnlib对程序集进行修改的方法，我们就可以实现删除程序集中用不到的类型的功能了，我们只要把对应的类型从ModuleDefMD的Types属性中删除掉即可。不过在实际操作中，这样做会遇到问题，因为我们要删除的类可能被其他的地方引用，尽管那些地方只是引用我们要删除的类，并没有真的调用，但是为了保证修改后程序集的校验合法性，ModuleDefMD的Write方法仍然会做合法性校验，否则Write方法就会抛出ModuleWriterException异常，比如：

ModuleWriterException: 'A method was removedthat 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(newInstruction(OpCodes.Nop) { Offset = 0 });
method.Body.Instructions.Add(newInstruction(OpCodes.Ldnull) { Offset = 1 });
method.Body.Instructions.Add(newInstruction(OpCodes.Throw) { Offset = 2 });

最后三行添加的IL代码就是对应thrownull这行C#代码。

请查看项目的github地址获取全部源代码，项目地址：

https://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方法会尽量保存本地代码的结构因此无法减小程序集的尺寸，甚至有可能反而增大程序集的尺寸。而且在实际使用的时候，我发现对于这些程序集进行修改之后，程序就会启动失败，查看Windows事件日志，我发现是程序启动的时候CLR启动失败造成的。根据Washi1337所说，如果只是程序集中含有ReadyToRun的本地代码，那么只要去掉程序集中的ILLibrary标志，让CLR跳过ReadyToRun本地代码，而直接执行IL代码就行了，毕竟对于ReadyToRun优化后的程序集仍然保存了原始的IL代码。但是我如Washi1337所说的操作之后，程序依旧启动失败，不清楚是什么原因，因为含有本地代码的程序集无法被很好的剪裁，因此我没有再深入研究，欢迎对CLR精通的朋友分享经验。
增大程序集的尺寸详见：

https://github.com/Washi1337/AsmResolver/issues/267

▍收获二：Dnlib的其他应用
由于DnLib可以修改程序集，因此我们可以使用它做很多的事情，比如修改程序的默认行为（你懂的）。我们可以使用DnLib编写一个自己的代码混淆器或者实现面向切面编程（AOP）的静态织入。

你还想到了哪些DnLib的应用场景？欢迎分享。

微软最有价值专家（MVP）

微软最有价值专家是微软公司授予第三方技术专业人士的一个全球奖项。29年来，世界各地的技术社区领导者，因其在线上和线下的技术社区中分享专业知识和经验而获得此奖项。
MVP是经过严格挑选的专家团队，他们代表着技术最精湛且最具智慧的人，是对社区投入极大的热情并乐于助人的专家。MVP致力于通过演讲、论坛问答、创建网站、撰写博客、分享视频、开源项目、组织会议等方式来帮助他人，并最大程度地帮助微软技术社区用户使用 Microsoft 技术。
更多详情请登录官方网站：
https://mvp.microsoft.com/zh-cn

文章转自公众号：openGauss