AssemblyLoadEventArgs用于在程序集加载后通知订阅者，通过AppDomain.AssemblyLoad事件传递已加载的Assembly对象，适用于监控、审计和分析程序集加载行为，如启动时依赖追踪或插件系统动态加载观察。
`.NET中的AssemblyLoadEventArgs类，简单来说，它是一个数据载体，当一个程序集（Assembly）被加载到应用程序域（AppDomain）时，它会把这个刚刚加载进来的程序集实例传递给事件订阅者。这样，你就能知道哪个程序集在什么时候“上线”了。
解决方案
在.NET的运行时环境中，程序集的加载是一个核心且频繁的操作，无论是显式通过Assembly.Load等方法，还是隐式因为代码引用而触发。AssemblyLoadEventArgs与AppDomain.CurrentDomain.AssemblyLoad事件紧密关联。当你订阅这个事件时，每当有新的程序集被加载到当前应用程序域，你的事件处理方法就会被调用，而AssemblyLoadEventArgs实例就是这次事件的“信使”，它携带着那个新加载的Assembly对象。
这提供了一个绝佳的观察点，让我们能够实时监控应用程序的内部动态。比如，你想知道你的应用程序在启动过程中到底加载了哪些DLL，或者一个插件系统在运行时加载了哪些扩展模块，AssemblyLoadEventArgs就是那个能告诉你答案的工具。它让你有机会在程序集被完全加载并准备好执行时，对其进行检查、记录甚至做一些自定义的后续处理。我个人觉得，这就像是给应用程序域装了一个“门禁系统”，每次有新的“访客”（程序集）进入，都会给你发个通知，并附上访客的详细信息。
AppDomain.AssemblyLoad 事件在哪些场景下会触发？
AppDomain.AssemblyLoad事件的触发场景其实比我们想象的要广泛，它不仅仅局限于你主动调用Assembly.Load的情况。理解这些场景，对于我们诊断问题或优化程序行为至关重要。
首先，最直接的就是显式加载。当你使用Assembly.Load、Assembly.LoadFrom、Assembly.LoadFile或AppDomain.Load等方法时，CLR会尝试加载指定的程序集，一旦成功，这个事件就会立即触发。这在插件架构或者需要动态加载模块的场景中非常常见。
其次，也是更隐蔽的，是隐式加载。这通常发生在你的代码首次引用一个位于不同程序集中的类型时。比如，你的主程序集A引用了库程序集B中的一个类B.SomeClass。当CLR首次遇到需要实例化B.SomeClass或者调用其静态成员时，如果程序集B尚未加载，CLR就会自动去查找并加载它。加载成功后，AssemblyLoad事件同样会触发。这种“按需加载”是.NET性能优化的一个策略，但对开发者而言，有时会觉得程序集加载时机有点“不可预测”。
再者，反射操作也可能导致程序集加载。当你通过反射去探索一个尚未加载的程序集中的类型信息，或者调用其方法时，CLR也可能需要加载那个程序集。
还有一些不那么常见的，比如序列化/反序列化。当序列化或反序列化一个对象时，如果其中包含了来自其他程序集的类型信息，CLR为了重建对象图，也可能需要加载相应的程序集。
对我来说，理解这些触发机制，让我能更好地预判应用程序的内存占用和启动时间，尤其是在大型、复杂的企业级应用中，有时一个不经意的引用，就可能导致一大堆程序集被加载进来，进而影响性能。
如何利用 AssemblyLoadEventArgs 监控应用程序的动态加载行为？
利用AssemblyLoadEventArgs监控动态加载行为，其实是一个非常直接且实用的手段。它提供了一个窗口，让我们能窥视到应用程序运行时内部的“心跳”——程序集的进出。
核心做法就是订阅AppDomain.CurrentDomain.AssemblyLoad事件。下面是一个简单的代码示例：
using System;
using System.Reflection;
using System.IO;
public class AssemblyMonitor
{
public static void StartMonitoring()
{
AppDomain.CurrentDomain.AssemblyLoad += CurrentDomain_AssemblyLoad;
Console.WriteLine("AssemblyLoad 事件监控已启动。");
}
public static void StopMonitoring()
{
AppDomain.CurrentDomain.AssemblyLoad -= CurrentDomain_AssemblyLoad;
Console.WriteLine("AssemblyLoad 事件监控已停止。");
}
private static void CurrentDomain_AssemblyLoad(object sender, AssemblyLoadEventArgs args)
{
Assembly loadedAssembly = args.LoadedAssembly;
Console.WriteLine($"[AssemblyLoaded] Name: {loadedAssembly.FullName}");
Console.WriteLine($" Version: {loadedAssembly.GetName().Version}");
Console.WriteLine($" Location: {loadedAssembly.IsDynamic ? "Dynamic Assembly" : loadedAssembly.Location}");
Console.WriteLine($" From GAC: {loadedAssembly.GlobalAssemblyCache}");
Console.WriteLine("--------------------------------------------------");
}
public static void Main(string[] args)
{
StartMonitoring();
// 模拟一些程序集加载行为
Console.WriteLine("\n--- 模拟显式加载 ---");
try
{
// 尝试加载一个不存在的程序集，会抛出异常，但不会触发AssemblyLoad
// Assembly.Load("NonExistentAssembly, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null");
// 应该加载一个真实存在的程序集，这里以System.Linq为例
Assembly.Load("System.Linq, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a");
}
catch (FileNotFoundException ex)
{
Console.WriteLine($"加载失败: {ex.Message}");
}
catch (Exception ex)
{
Console.WriteLine($"发生错误: {ex.Message}");
}
Console.WriteLine("\n--- 模拟隐式加载 ---");
// 引用一个可能尚未加载的类型，例如来自 System.Net.Http
// 如果 System.Net.Http 尚未加载，此处会触发隐式加载
try
{
_ = new System.Net.Http.HttpClient();
}
catch (Exception ex)
{
Console.WriteLine($"创建HttpClient失败 (可能是.NET Core/5+版本，System.Net.Http已随App加载): {ex.Message}");
}
// 确保有足够时间观察输出
Console.WriteLine("\n按任意键退出...");
Console.ReadKey();
StopMonitoring();
}
}在这个例子中，CurrentDomain_AssemblyLoad方法就是我们的事件处理程序。当任何程序集被加载时，它都会被调用，args.LoadedAssembly会给我们提供一个Assembly对象。通过这个对象，我们可以获取到程序集的FullName（包含名称、版本、文化、公钥令牌等）、Location（物理路径，如果是动态生成的则没有）、IsDynamic（是否为动态程序集）、GlobalAssemblyCache（是否来自GAC）等信息。
实际应用中，这种监控可以用于：
- 调试与审计： 记录所有加载的程序集，帮助我们理解应用程序的依赖关系，或者在生产环境中追踪异常加载。
- 性能分析： 识别哪些程序集在启动时加载，它们的加载顺序和大小，从而找出潜在的启动瓶颈。
- 安全检查： 检测是否有未经授权或来源不明的程序集被加载，这在某些高安全要求的环境中非常有用。
- 资源管理： 在某些复杂场景下，你可能需要根据加载的程序集来动态调整资源分配或配置。
需要注意的是，AssemblyLoad事件在程序集被加载到内存后触发，它并不能阻止加载。如果需要干预加载过程，你可能需要考虑AssemblyResolve事件。
AssemblyLoadEventArgs 与 AssemblyResolveEventArgs 有何不同，各自的应用侧重是什么？
AssemblyLoadEventArgs和AssemblyResolveEventArgs虽然都与程序集加载有关，但它们在职责和应用场景上有着本质的区别。我经常把它们比作两个不同阶段的“报告员”。
AssemblyLoadEventArgs (与 AppDomain.AssemblyLoad 事件)
-
作用： 这是一个通知机制。当CLR成功地找到并加载了一个程序集后，它会触发
AppDomain.AssemblyLoad事件，并通过AssemblyLoadEventArgs把这个已经加载好的Assembly对象传递给你。 - 关注点： “什么程序集被加载了？”、“加载后的程序集信息是什么？”
- 应用侧重： 主要是监控、审计、记录、分析。你用它来观察应用程序的动态行为，了解哪些模块在何时进入了应用程序域。它是一个事后通知，你不能通过它来改变加载行为，只能在加载完成后做出反应。比如，你想要记录应用程序启动时加载的所有DLL，或者你想在插件加载后执行一些初始化操作。
AssemblyResolveEventArgs (与 AppDomain.AssemblyResolve 事件)
-
作用： 这是一个干预/解决机制。当CLR尝试加载一个程序集，但未能成功找到它时（例如，程序集不在预期的路径，或者版本不匹配），它会触发
AppDomain.AssemblyResolve事件，并通过AssemblyResolveEventArgs告诉你它正在寻找哪个程序集（通过Name属性）。此时，你有机会介入，手动定位并返回正确的Assembly对象。 - 关注点： “CLR找不到哪个程序集？”、“我能提供这个程序集吗？”
-
应用侧重： 主要是自定义程序集解析逻辑。你用它来解决程序集加载失败的问题，或者从非标准位置（如嵌入资源、自定义文件系统、网络位置）加载程序集。它是一个事前干预，你的事件处理程序需要返回一个
Assembly对象，否则CLR会继续认为加载失败。这在插件系统、版本兼容性处理、或者部署复杂应用时非常有用。例如，你的应用程序需要加载一个特定版本的库，但该库可能存在于多个位置，或者被重命名了，你就可以通过AssemblyResolve事件来引导CLR找到正确的程序集。
总结一下：
-
AssemblyLoadEventArgs： “我已经加载好了，告诉你一声。”——用于观察。 -
AssemblyResolveEventArgs： “我找不到这个，你能帮我找找吗？”——用于干预。
两者协同使用时，可以构建出非常健壮和灵活的应用程序加载机制。比如，你可能先用AssemblyResolve来解决程序集的查找问题，一旦成功找到并加载，AssemblyLoad事件又会告诉你这个程序集已经被加载进来了，你可以进一步记录或处理。它们是.NET运行时提供给开发者管理程序集生命周期的两把不同但同样重要的钥匙。
