.net WiX通用自定义操作程序集合并vs ILMerge

当使用WiX工具集构建.NET自定义操作项目时，它似乎会合并直接项目引用中所有可能需要的代码，同时丢弃不需要的代码路径。这是对行为的正确解释吗？如果是的话，可能会有什么样的缺点（例如反射问题）

---

这个系统是否可以在安装程序项目之外以某种方式代替ILMerge进行更广泛的使用？

AFAIK

makesfxca.exe

（这就是你所说的工具，不是吗？）从纯技术意义上讲，并不是在合并dll。它采用自己的本机“存根”-名为

SfxCA.dll

的dll附加/打包其他依赖项（例如WIX自己的

Microsoft.Deployment.WindowsInstaller

以及包含自定义操作的IL代码的托管dll），创建能够“自提取”的本机dll。安装msi时，会临时提取此存档

因此，它通过将传入的dll复制到

makesfxca

中来“解析”项目引用，从而能够省略仅引用但未本地复制的.Net framework dll的包含。我不确定它是否真的会丢弃任何东西

---

ILMerge

另一端处理托管dll文件，进行真正的合并，而不是打包和以后提取文件。

好吧，在一个安装程序项目中，我有23MB的引用，必须链接进去，这将简化为一个大约2.7MB的自定义操作DLL。只要您只引用例如.Net 2.0 DLL，如

System.Data

或

System.XML

，并且不将它们复制到输出目录（假设采用标准DTF构建过程），就不会将这些库拖到生成的

*.CA.DLL

。例如，将

系统的标记“Copy local”设置为true。Data

会导致

*.CA.dll

大800千字节（这可能计算为库的压缩大小，在我的计算机上它的原始大小为2884千字节）。不过，我不计算.NET framework引用。这些是从另一个解决方案内部开发的托管代码程序集。基本上，我引用的是类A、B和C。并不是所有的类都被使用，而是A调用了B中的一些方法，这些方法调用了C中在安装过程中使用的一些方法。同时，A、B和C的完整大小远远超过了能够正常工作的输出DLL的大小。编辑了我的答案，扩展了我在上述评论中提到的内容。酷，那么你是说它实际上所做的就是压缩所有引用，不管它们是否被使用，并将它们放入非托管程序集中？