deployment - 一个大的可执行文件还是许多小的DLL?

标签 deployment dll executable

多年来,我的应用程序已从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的使用以及易于部署与轻松/快速开发之间的最佳“平衡”有何看法?

    最佳答案

    单个可执行文件对可维护性具有巨大的积极影响。在现场进行调试,部署(排除问题大小)和进行诊断更容易。正如您指出的那样,它完全避开了DLL的 hell 。

    解决问题的最直接的方法是拥有两种编译模式,一种编译用于生产的单个exe文件,另一种编译用于开发的小DLL。

    关于deployment - 一个大的可执行文件还是许多小的DLL?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/2881296/

    相关文章:

    c++ - win32 - .dll 中的对话框

    executable - 如何将 Electron 应用程序打包成单个可执行文件?

    go - 有什么方法可以通过 go get 安装可执行文件和库?

    xcode - 如何在我的项目中嵌入可执行文件

    java - 如何等待 spring cron 作业从 ant build 脚本完成

    java - Java Web 应用程序的多上下文

    azure - EventHub 的 Azure 部署期间出现 429 错误

    .net - 编写 Visual Studio 构建脚本、Clickonce 部署、Dotfuscator 和 Mage

    c - 像这样的 C "spec"文件是如何创建的?

    c - 如何混淆非托管dll的函数名