SnoopWPF项目中注入RPC服务时的依赖加载问题解析

问题背景

在使用SnoopWPF项目进行WPF应用程序注入时，开发者尝试将一个包含JSON-RPC服务的SimpleUIAutomation.dll注入到目标应用程序中。虽然注入过程本身成功执行，但在运行时却遇到了StreamJsonRpc程序集加载失败的问题。

核心问题分析

当通过SnoopWPF的注入机制将自定义DLL加载到目标应用程序时，.NET的默认程序集探测机制会从应用程序启动目录查找依赖项，而不是从注入DLL所在目录查找。这就导致了即使StreamJsonRpc.dll存在于注入DLL的同目录下，运行时仍然无法找到该依赖项。

技术原理

.NET程序集加载机制在解析依赖时遵循以下顺序：

1. 首先检查GAC(全局程序集缓存)
2. 然后检查应用程序基目录
3. 最后检查配置文件指定的私有路径

在DLL注入场景中，注入的DLL及其依赖项通常位于与主应用程序不同的目录中，因此默认的探测机制无法定位这些依赖项。

解决方案

针对这个问题，可以采用以下几种解决方案：

方案一：显式加载依赖项

在注入的代码中，首先显式加载所需的依赖项：

// 在访问任何依赖项功能前加载
Assembly.LoadFrom(Path.Combine(
    Path.GetDirectoryName(Assembly.GetExecutingAssembly().Location), 
    "StreamJsonRpc.dll"));

方案二：处理AppDomain.AssemblyResolve事件

更健壮的解决方案是处理AppDomain的AssemblyResolve事件，自定义程序集解析逻辑：

AppDomain.CurrentDomain.AssemblyResolve += (sender, args) => {
    var assemblyName = new AssemblyName(args.Name).Name;
    if(assemblyName == "StreamJsonRpc") {
        string path = Path.Combine(
            Path.GetDirectoryName(Assembly.GetExecutingAssembly().Location),
            "StreamJsonRpc.dll");
        return Assembly.LoadFrom(path);
    }
    return null;
});

方案三：合并依赖项

使用ILMerge等工具将依赖项合并到主DLL中，这样就不需要单独加载依赖项。

最佳实践建议

1. 依赖管理：对于注入场景，建议将所有依赖项放在同一目录，并确保它们都能被正确加载
2. 错误处理：在加载依赖项时添加适当的错误处理和日志记录
3. 版本兼容性：确保注入的DLL与其依赖项的版本兼容
4. 资源清理：对于需要清理的资源(如命名管道)，确保有适当的释放机制

总结

在SnoopWPF等注入工具的使用过程中，依赖项加载是一个常见问题。理解.NET的程序集加载机制并采取适当的解决方案，可以确保注入的代码能够正确运行。显式加载依赖项是最直接的解决方案，而处理AssemblyResolve事件则提供了更灵活的依赖管理方式。开发者应根据具体场景选择最适合的解决方案。