我正在 Visual Studio 2010 上开发 C++ Windows 应用程序。
我想将我的应用程序交付给我的客户,以便他可以轻松使用它,而无需安装可视化运行时 fx。并处处处决。
如何设置安装程序,以便客户无需单独安装任何所需的 Visual Studio 运行时库?
我想要一个解决这个问题的方法,因为我的客户离计算太远了,他们只喜欢“下一步,下一步,安装,完成”系统。
谢谢您的帮助。
我正在 Visual Studio 2010 上开发 C++ Windows 应用程序。
我想将我的应用程序交付给我的客户,以便他可以轻松使用它,而无需安装可视化运行时 fx。并处处处决。
如何设置安装程序,以便客户无需单独安装任何所需的 Visual Studio 运行时库?
我想要一个解决这个问题的方法,因为我的客户离计算太远了,他们只喜欢“下一步,下一步,安装,完成”系统。
谢谢您的帮助。
一般来说,您有两种选择:
构建安装程序(例如,使用 WiX 或 NSIS)。安装程序将安装您的应用程序以及任何所需的库。由于您正在分发您的应用程序,因此您可能已经在构建安装程序,因此此解决方案是有意义的。
将您的文件与任何所需的库静态链接。这样,您的应用程序可执行文件包含它需要的所有代码。当然,这假设您正在使用的库可以静态链接。情况可能并非如此。
您可以静态链接您的产品,使其没有任何外部依赖项,或者在构建安装程序时为您需要的运行时组件包含 MSI合并模块。
通常,选项是静态链接、私有部署、使用合并模块以重用其他人的逻辑或通过使用引导程序重新分配先决条件。
如果不知道您的确切依赖关系是什么,就不可能给出确切的答案,但这里是每个方面的优缺点:
静态链接 - 很容易,因为除了您的文件之外没有什么可以部署的。主要缺点是如果库具有安全漏洞并且需要修补,则必须重新构建和重新部署应用程序。
私有部署 - 相对容易,因为您只需将文件部署在应用程序目录中。由于您必须重建和重新部署应用程序,因此仍然存在服务问题。Microsoft 不会修补您的目录。
合并模块 - 看起来很简单,只需添加合并模块。但是仍然存在重大问题,因为如果合并模块出现问题,您将受到供应商的摆布。(微软)。这就是为什么现在不赞成使用合并模块的原因。
redist - 最难实现(您需要定义 setup.exe 引导程序),但也最简单,因为您可以重复使用其他人的安装程序。这是最佳的,因为该供应商可以在不重建您的情况下修补该 dll。
所以一般来说,redists是要走的路。但不总是... :)