Dynamics 365中替换ILMerge：寻求可用DLL合并工具及正确用法

我负责Dynamics 365工作流/动作的外部包组装项目，添加Microsoft Graph包后，ILMerge无法将其合并到程序集中，因此打算弃用ILMerge，但暂未找到合适替代方案。我尝试使用LibZ，认为场景符合Scenario 1，但未达预期：

• 操作方式：打开NuGet包控制台，进入bin/Release目录执行命令：

  libz inject-dll --assembly MyAssembly.dll --include *.dll --exclude MyAssembly.dll --move
  

• 结果：命令修改了程序集，但结构与ILMerge生成的版本不同（可通过ILSpy对比，ILSpy可通过winget install XP8C26VDWLP4T4安装）；LibZ生成的程序集虽能通过Plug-in Registration Tool加载，但所有工作流均无法正常运行。

请问我是否错误使用了LibZ，或是否有其他工具能实现ILMerge的有效合并效果？

一、LibZ使用的问题分析 #

你的LibZ命令语法本身是正确的，但机制不匹配Dynamics 365工作流的运行要求：

• LibZ的inject-dll是将依赖DLL嵌入主程序集作为资源，运行时通过动态加载的方式读取，和ILMerge直接合并IL代码的逻辑完全不同。
• Dynamics 365的插件/工作流运行环境对动态加载的支持有限，尤其是类型解析、强命名验证环节，很容易导致工作流执行失败。

二、推荐替代工具 #

1. ILRepack #

ILRepack是ILMerge的开源替代，兼容性更强，能更好处理Microsoft Graph这类复杂依赖：

• 安装：通过NuGet包ILRepack安装，或直接下载独立工具
• 示例命令（进入bin/Release目录执行）：

  ILRepack /out:MergedMyAssembly.dll MyAssembly.dll *.dll /exclude:MyAssembly.dll /keyfile:YourStrongNameKey.snk
  

  注意：如果原程序集有强命名，必须用/keyfile指定密钥重新签名，否则无法在Dynamics 365中正常运行。

2. Costura.Fody #

这是一款通过编译注入实现依赖嵌入的工具，配置简单，适合Dynamics 365项目：

• 步骤：
  1. 在项目中安装NuGet包Costura.Fody
  2. 项目根目录会生成FodyWeavers.xml，可自定义嵌入规则（默认自动嵌入所有非系统依赖）
  3. 直接编译项目，生成的程序集已包含所有依赖，无需额外命令

3. 通用注意事项 #

• 不要合并Dynamics 365的系统程序集（如Microsoft.Xrm.Sdk.dll、Microsoft.Crm.Sdk.Proxy.dll等），这些由平台提供，打包进去会引发冲突。
• 合并后务必验证程序集的强命名有效性，可通过sn -v MergedAssembly.dll命令检查。
• 测试时建议先合并少量依赖，逐步排查问题，避免一次性合并所有DLL导致难以定位错误。

内容的提问来源于stack exchange，提问作者YanMax