一个大的可执行文件或很多小的DLL？

Question

多年来我的应用程序已经从1MB增长到了25MB，我预计它会进一步增长到40,50 MB。我不使用DLL，而是将所有内容放在这个大的可执行文件中。

有一个大的可执行文件具有一定的优势：

• 我安装在客户应用程序真正做到：复制和运行。
• 升级就可以很容易地压缩和发送给客户
• 没有有冲突的DLL的风险（如客户有EXE的X版本，但DLL版本Y）

大大型EXE的缺点是连接时间似乎呈指数级增长。

另一个问题是，一部分代码（比如约40％）与另一个应用程序共享。再次，优点是：

• 有在具有不正确的DLL版本
• 每个开发人员都可以在其上加快发展的共同代码变化的组合没有风险。

但是，这又对编译时间产生了严重的影响（每个人都会在PC上再次编译通用代码）和链接时间。

问题Grouping DLL's for use in Executable提到了在一个可执行文件中混合DLL的可能性，但它看起来仍然需要您在应用程序中手动链接所有函数（使用LoadLibrary，GetProcAddress，...）。

对于可执行文件的大小，使用DLL以及简单部署和简单/快速开发之间的最佳“平衡”，您有何看法？

Answer 1

单个可执行文件对可维护性有着巨大的积极影响。调试，部署（尺寸问题放在一边）和现场诊断更容易。正如你指出的那样，它完全避开了DLL地狱。

对于你的问题最直接的解决方案是有两种编译模式，一种是为生产构建一个exe文件，另一种是为开发构建大量小DLL。

Answer 2

一个大的可执行文件绝对是有益的 - 你可以有整个程序优化和更少的开销，维护更简单。

至于链接时间 - 你可以同时拥有“多个DLL”和“一个大的可执行文件”。对于每个DLL都有一个构建静态库的项目配置。因此，当您调试项目时，需要编译项目的“DLL”配置，并且在需要发布时编译项目的“静态库”配置。有时你会在不同的配置中有不同的行为，但这必须在每个事件中处理。

Answer 3

维护大型程序的一种更简单的方法是将它们组合成更小的可管理部分。一个程序可以组成一个shell和一些模块，这些模块可以为shell添加功能。像Visual Studio，Outlook这样的大型程序都使用相同的概念。尝试使用这种方法来制作更可维护，更健壮的程序。

Answer 4

的宗旨是：减少你的数量。NET程序集严格最低限度为。有一个单一的组件是理想的数字。这就是例如Reflector或NHibernate的情况，它们都是非常少的程序集。

参数在这些白书开发

• Partitioning code base through .NET assemblies and Visual Studio projects（8页）
• Defining .NET Components with Namespaces（共7页）：我公司在话题一个很大的可执行文件或很多小DLL的公布free two white books以无效/有效的原因来创建程序集的代码库和案例研究NDepend。

  问题是，MS培养（并且仍在培养）这样的想法，即组件是组件，而组件只是物理工件来打包代码。组件的概念是逻辑工件，通常组件应包含多个组件。尽管分配组件并不总是可行的（尤其是在使用公共API的框架，其中命名空间用于对API进行分区而不一定是组件）的情况下，这是一个好主意。