我想知道在创建要包含在与依赖项相关的其他项目中的库版本时是什么启发式，以及是否应该包含它们。
我的问题如下：
我有一个CommonUtilities库，它提供了一组可以在多个地方使用的实用程序。 CommonUtilities的依赖包括log4net.dll（日志框架）和Oracle.DataAccess.dll（数据库驱动程序）。
我有另一个名为MyProject的项目，我希望将CommonUtilities包含在内.MyProject还依赖于Oracle.DataAccess。
如果我使用ILMerge并将CommonUtilities合并到单个程序集CommonUtilities.dll中并引用来自MyProject的一切编译，但我确信我应该从MyProject显式引用Oracle.DataAccess，因为它是依赖项而不是使用汇编到CU的程序集。添加对Oracle.DataAccess的引用也会导致使用不明确的语句，因为引用了两个Oracle.DataAccess程序集。
在我的情况下使用ILMerge / Internalize会导致编译错误，因为内部化的Oracle.DataAccess程序集中的类型是从CommonUtilities返回的，因为它们被标记为内部MyProject无法识别返回的类型。
使这项工作的唯一方法就是不将这个特定的程序集（Oracle.DataAccess）合并到CommonUtilities中，而只是从MyProject引用它。 这又会产生一个新问题：我应该引用哪个Oracle.DataAccess.dll - 与CommonUtils一起分发的依赖关系？
还有其他方法可以解决这一切吗？
答案 0 :(得分：5)
简短的版本：
一个流程中对给定程序集的每个引用都应引用相同的版本。
如果你不这样做，你可能会陷入深深的麻烦，因为版本不匹配导致应用程序的某个部分无法与另一部分交谈。
即使使用像log4net这样的“非常私密”的东西，您也可能会错过共享配置空间的可能性，例如对应用程序的所有部分使用通用根记录器。当然，在这种情况下的最后一次调用是 - 一如既往 - 与负责任的开发人员一起。
另请参阅有关ILMerge and 3rd party assemblies的其他问题。
答案 1 :(得分：4)
我们使用ILMerge的最大原因是使我们的混淆步骤更加难以逆转。通过使用/ internalize标志将它们合并在一起，混淆器可以重命名我们合并到父组件中的公共类和方法。
来自IL合并文档： “[Internalize]控制主程序集以外的程序集中的类型是否已修改其可见性。如果为true，则在程序集外部可见的所有非免除类型的可见性都会被修改，以便从外部看不到它们。合并的集合“
如果程序集保持独立，则混淆器不会重命名它们。
BTW Eazfuscator真棒，免费： http://www.foss.kharkov.ua/g1/projects/eazfuscator/dotnet/Default.aspx
答案 2 :(得分：1)
我们根本不合并库。我无法看到将图书馆合并在一起的很多优点，而不是仅仅在一个装配体中构建它们。
我可以看到将库与EXE合并的好处。这可能非常方便。将库合并在一起的问题在于它们可能在您的EXE中具有不同版本的依赖性，这可能会导致不舒服的同伴。
我不认为将dll合并在一起可能被视为最佳实践，除非您将它们合并到EXE中以呈现单个文件而不是多个文件。
答案 3 :(得分：0)
我认为将一堆本地化的程序集保存在一个中可能会有一些优势（我甚至不确定你能做到）
我不会合并来自其他供应商的库 - 因为他们通常拥有自己的许可，更新它们需要您重新分发新版本的代码。
如果您有许多库来保持目录整洁，或者确保某些代码始终与主执行程序集一起使用，那么合并您自己的库可能是有利的。
我认为ILMerge在将库合并到EXE中会更好，所以你有一个文件而不是很多。