ILMerge最佳做法
我们是否使用ILMerge？我们是否使用ILMerge合并多个程序集以简化dll的部署？将ILMerging组合在一起后，我们是否发现生产中的部署/版本化问题？
我正在寻找有关使用ILMerge减少部署冲突的建议，即使可能的话。
解决方案
回答
我们在许多项目上使用ILMerge。例如，Web Service Software Factory产生的输出类似于8个程序集。我们将所有这些DLL合并到一个DLL中，以便服务主机仅需引用一个DLL。
它使生活更轻松一些，但也没什么大不了的。
回答
我们在Microsoft应用程序块上使用ILMerge而不是12个单独的DLL文件，我们有一个文件可以上载到客户区，而且文件系统结构更加整洁。
合并文件后，我必须编辑Visual Studio项目列表，删除12个单独的组件，并添加单个文件作为参考，否则它将抱怨找不到特定的程序集。我不太确定这在后期部署中如何工作，值得尝试一下。
回答
到目前为止，我们才刚刚开始在我们的解决方案中使用ILMerge，这些解决方案已在其他项目中重新分发和使用。一切似乎都正常。我们甚至直接混淆了打包的程序集。
我们正在考虑对MS Enterprise Library程序集进行相同的操作。
我看到的唯一真正的问题是软件包中各个组件的版本控制。
回答
我几乎将所有不同的应用程序都使用ILMerge。我已经将它集成到发行版本的构建过程中，因此最终得到的是每个应用程序一个exe，没有额外的dll。
我们不能将任何具有本机代码的C ++程序集合并。
我们也不能ILMerge包含XAML for WPF的程序集(至少我还没有成功)。它在运行时抱怨找不到资源。
我确实为ILMerge编写了一个包装可执行文件，在其中传递了我要合并的项目的启动exe名称和输出exe名称，然后它反映了相关程序集，并使用适当的命令行参数调用了ILMerge。现在，当我将新程序集添加到项目中时，它变得容易得多，无需记住要更新构建脚本。
回答
合并具有相同命名空间中的资源的DLL时，我们会遇到问题。在合并过程中，资源名称空间之一被重命名，因此无法找到资源。也许我们在这里做错了什么，仍在调查问题。
回答
最近，我遇到一个问题，即我在程序集中没有使用程序集，而在Umbraco开源CMS中有一些通过反射被调用的类。
通过反射进行调用的信息来自具有表名，已实现的类和接口的db表。问题是，当dll被il合并时，反射调用将失败，但是如果将dll分开，则它们都可以正常工作。我认为问题可能类似于longeasy所遇到的问题？
回答
在我看来，＃1 ILMerge最佳实践是"不要使用ILMerge"。而是使用SmartAssembly。原因之一是＃2 ILMerge最佳实践是在执行ILMerge之后始终运行PEVerify，因为ILMerge不保证它将正确地将程序集合并为有效的可执行文件。
ILMerge的其他缺点：
- 合并时，它会剥离XML注释(如果我对此很在意，我会使用混淆工具)
- 它不能正确处理创建相应的.pdb文件
另一个值得关注的工具是Mono.Cecil和Mono.Linker [2]工具。
[2]：http：// www.mono-project.com/Linker
