多年来，我的应用程序从1MB增长到25MB，我预计它将进一步增长到40,50 MB。我不使用DLL，但将所有内容放在这个大的可执行文件中。
拥有一个大的可执行文件具有一定的优势：
大型EXE的最大缺点是连接时间似乎呈指数级增长。
另外一个问题是代码的一部分（假设大约40％）与另一个应用程序共享。同样，优点是：
但同样，这会对编译时间产生严重影响（每个人都会在PC上再次编译公共代码）和链接时间。
问题Grouping DLL's for use in Executable提到了将DLL混合在一个可执行文件中的可能性，但看起来这仍然需要您在应用程序中手动链接所有函数（使用LoadLibrary，GetProcAddress，...）。
您对可执行文件大小，DLL的使用以及易于部署和轻松/快速开发之间的最佳“平衡”有何看法？
答案 0 :(得分：14)
单个可执行文件对可维护性产生巨大的积极影响。在现场调试，部署（调整大小问题）和诊断更容易。正如你所指出的那样，它完全回避了DLL地狱。
对你的问题最直接的解决方案是有两种编译模式，一种为生产构建单个exe，另一种为开发构建许多小DLL。
答案 1 :(得分：4)
原则是：将.NET程序集的数量减少到严格的最小值。单个组件是理想的数字。例如，Reflector或NHibernate的情况都是非常少的组件。我的公司发布了free two white books主题一个大的可执行文件或许多小DLL的：
在这些白皮书中开发的参数是无效/有效的原因，以便在工具NDepend的代码库上创建程序集和案例研究。
问题在于MS促进（并且仍在培养）组件是组件的想法，而组件只是物理工件来打包代码。组件的概念是逻辑工件，通常程序集应包含多个组件。使用命名空间概念对组件进行分区是一个好主意，尽管它并不总是切实可行（特别是在具有公共API的框架的情况下，其中命名空间用于对API进行分区而不一定是组件）
答案 2 :(得分：2)
一个大的可执行文件肯定是有益的 - 您可以进行整个程序优化，减少开销，维护更简单。
至于链接时间 - 你可以同时拥有“多个DLL”和“一个大的可执行文件”。对于每个DLL都有一个构建静态库的项目配置。因此，当您调试项目时，您需要编译项目的“DLL”配置，并在需要发布时编译项目的“静态库”配置。有时您会在不同的配置中有不同的行为，但每次事件都必须解决这个问题。
答案 3 :(得分：2)
维护大型程序的一种更简单的方法是将它们组合成较小的可管理部分。程序可以组成一个shell和模块，为shell添加功能。像Visual Studio，outlook这样的大型程序都使用相同的概念。尝试这种方法来制作更易于维护和健壮的程序。