一个大的可执行文件还是许多小的 DLL？
多年来，我的应用程序已从 1MB 增长到 25MB，我预计它会进一步增长到 40、50MB。我不使用 DLL，而是将所有内容都放在这个大的可执行文件中。
拥有一个大的可执行文件具有一定的优势：
- 在客户处安装我的应用程序实际上是：复制并运行。
- 升级可以轻松压缩并发送给客户
- 不存在 DLL 冲突的风险（客户没有 EXE 版本 X，而是 DLL 版本 Y）
大 EXE 的一大缺点是链接时间似乎呈指数级增长。
另一个问题是部分代码（假设大约 40%）与另一个应用程序共享。同样，优点是：
- 不存在混合使用不正确的 DLL 版本的风险
- 每个开发人员都可以对通用代码进行更改，从而加快开发速度。
但同样，这对编译时间（每个人都在他的 PC 上再次编译公共代码）和链接时间产生了严重影响。
问题Grouping DLL's for use in Executable提到了将DLL混合在一个中的可能性可执行文件，但看起来仍然需要您在应用程序中手动链接所有函数（使用 LoadLibrary、GetProcAddress，...）。
您对可执行文件大小、DLL 的使用以及轻松部署和轻松/快速开发之间的最佳“平衡”有何看法？
Over the years my application has grown from 1MB to 25MB and I expect it to grow further to 40, 50 MB. I don't use DLL's, but put everything in this one big executable.
Having one big executable has certain advantages:
- Installing my application at the customer is really: copy and run.
- Upgrades can be easily zipped and sent to the customer
- There is no risk of having conflicting DLL's (where the customer has not version X of the EXE, but version Y of the DLL)
The big disadvantage of the big EXE is that linking times seem to grow exponentially.
Additional problem is that a part of the code (let's say about 40%) is shared with another application. Again, the advantages are that:
- There is no risk on having a mix of incorrect DLL versions
- Every developer can make changes on the common code which speeds up developments.
But again, this has a serious impact on compilation times (everyone compiles the common code again on his PC) and on linking times.
The question Grouping DLL's for use in Executable mentions the possibility of mixing DLL's in one executable, but it looks like this still requires you to link all functions manually in your application (using LoadLibrary, GetProcAddress, ...).
What is your opinion on executable sizes, the use of DLL's and the best 'balance' between easy deployment and easy/fast development?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
单个可执行文件对可维护性具有巨大的积极影响。现场调试、部署（尺寸问题除外）和诊断更加容易。正如您所指出的，它完全避开了 DLL 地狱。
解决您的问题的最直接的解决方案是采用两种编译模式，一种为生产构建单个 exe，另一种为开发构建大量小 DLL。
A single executable has a huge positive impact on maintainability. It is easier to debug, deploy (size issues aside) and diagnose in the field. As you point out, it completely sidesteps DLL hell.
The most straightforward solution to your problem is to have two compilation modes, one that builds a single exe for production and one that builds lots of little DLLs for development.
原则是：将 .NET 程序集的数量严格限制在最低限度。拥有一个组件是理想的数量。例如，Reflector 或 NHibernate 就是这种情况，它们都是很少的程序集。我的公司发布了关于主题一个大的可执行文件或许多小 DLL 的免费两本白皮书 ：
参数是在这些白色中开发的-书籍附带了创建程序集的无效/有效原因以及关于工具代码库的案例研究 NDepend 。
问题在于，MS 提倡（并且仍在提倡）程序集是组件，而程序集只是打包代码的物理工件的观念。组件的概念是一个逻辑工件，通常一个程序集应包含多个组件。使用命名空间的概念来划分组件是一个好主意，尽管它并不总是可行（特别是在具有公共 API 的框架的情况下，其中命名空间用于划分 API 而不一定是组件）
The tenet is: reduce the number of your .NET assemblies to the strict minimum. Having a single assembly is the ideal number. This is for example the case for Reflector or NHibernate that both come as a very few assemblies. My company published free two white books on the topic One big executable or many small DLL's:
Arguments are developed in these white-books come with invalid/valid reasons to create an assembly and a case study on the code base of the tool NDepend.
The problem is that MS fosters(and is still fostering) the idea that assemblies are components while assemblies are just physical artifact to pack code. The notion of component is a logical artifact and typically an assemblies should contains several components. It is a good idea to partition component with the notion of namespaces although it is not always practicable (especially in the case of a framework with a public API where namespace are used to partition the API and not necessarily the components)
一个大的可执行文件绝对是有益的 - 您可以优化整个程序，减少开销，并且维护也更加简单。
至于链接时间 - 您可以同时拥有“许多 DLL”和“一个大的可执行文件”。对于每个 DLL 都有一个构建静态库的项目配置。因此，当您调试东西时，您会编译项目的“DLL”配置，而当您需要发布时，您会编译项目的“静态库”配置。有时，您在不同的配置中会有不同的行为，但这必须针对每个事件进行解决。
One big executable is definitely beneficial - you can have whole program optimization and less overhead and maintenance is much simpler.
As for the link time - you could have both the "many DLLs" and "one big executable" at the same time. For each DLL have a project configuration that builds a static library. So when you debug things you compile the "DLL" configuration of the project and when you need to ship you compile the "static library" configurations of your projects. Sometimes you will have different behavior in different configurations, but this will have to be addressed per incident.
维护大型程序的一种更简单的方法是将它们组合成更小的可管理部分。程序可以组成 shell 和向 shell 添加功能的模块。像 Visual Studio、outlook 这样的大型程序都使用相同的概念。尝试这种方法来制作更易于维护和健壮的程序。
An easier way to maintain large programs is to compose them into smaller manageable parts. A program can be composed into a shell and modules that add feature to the shell. Large programs like Visual Studio, outlook all use the same concepts. Try this approach to make a more maintainable and robust programs.