我们的VB6应用程序在很大程度上依赖于使用scrrun.dll（Windows Scripting Host）。直到一年前，我们还使用安装程序部署了这个dll。 Since the Windows Scripitng Host is supposed to be part of Windows我们从安装包中删除了dll。但是，偶尔会在客户系统中使用非功能性scrrun.dll，我们必须帮助他们重新安装或重新注册。
那么，我们应该将scrrun.dll放回安装包吗？我们应该对安装进行一些检查吗？或者我们是否应该接受这样一个事实，即我们必须为我们的一些客户提供支持以正确设置他们的系统？
答案 0 :(得分：5)
Don't try to deploy these libraries as part of a normal setup.
必须通过使用a安装Microsoft Scripting Runtime 自解压.exe文件。对于提到的Scripting Runtime版本 在本文开头，分发它的唯一方法是 使用位于以下位置的完整自解压.exe文件 地点...
有些用户可能会使用较旧的反恶意软件套件，其中许多都试图禁用脚本。更有可能的是，有些用户设法破坏了他们的Windows安装，无论是他们自己还是使用不正确打包的应用程序试图包含这些库 - 并在卸载时盲目地从系统中删除它们（咳嗽，咳嗽 - Inno < / em>的）。
所涉及的图书馆已经定制了一段时间的代码。这就是古代.CAB文件很久以前被“召回”的原因。没有任何一个副本可以在任何随机版本的Windows上运行，并且没有适用于任何现代版本Windows的redist包。正确的修复是系统还原或修复安装。
虽然这不能直接归咎于InnoSetup，因为它是由于编写得不好的脚本造成的，但它足够令人沮丧且足够常见，以至于当其签名被添加到反恶意软件套件时我不会哭。在太多人的野外复制/粘贴中，有太多写得不好的例子。
我花了很多时间来解除因卸载这些应用程序而造成的损害，并且已经非常厌倦了。在可能的情况下，我现在使用隔离组件进行自卫，这有很大帮助。 Windows File Protection在防止系统文件滥用行为方面也越来越好。
但总的来说，最好避免在应用程序中依赖脚本工具。尽管编写替代逻辑可能需要一些时间，但他们无论如何都可以做到直接代码。