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