我们的 VB6 应用程序严重依赖于 scrrun.dll（Windows 脚本宿主）的使用。直到一年前，我们还使用我们的安装程序来部署这个 dll。由于 Windows 脚本主机应该是 Windows 的一部分，我们从安装包中删除了 dll。但是，有时会出现在他们的系统上具有非功能性 scrrun.dll 的客户，我们必须帮助他们重新安装或重新注册它。
那么，我们是否应该将 scrrun.dll 放回安装包中呢？我们应该对安装进行一些检查吗？或者我们是否应该接受这样一个事实，即我们必须为一些客户提供手动支持以正确设置他们的系统？
Microsoft Scripting Runtime 必须通过使用自解压 .exe 文件来安装。对于本文开头提到的 Scripting Runtime 版本，分发它的唯一方法是使用位于以下位置的完整自解压 .exe 文件...
一些用户可能使用较旧的反恶意软件套件，其中许多试图禁用脚本。更有可能的是，一些用户已经设法破坏了他们的 Windows 安装，无论是他们自己还是通过使用未正确打包的应用程序来尝试包含这些库 - 并在卸载时盲目地将它们从系统中删除（咳嗽，咳嗽 - Inno）。
所涉及的库已经定制了一段时间的代码。这就是为什么古老的 .CAB 文件很久以前就被“召回”了。它们没有一个副本可以在任何随机版本的 Windows 上运行，也没有适用于任何现代版本的 Windows 的 redist 包。正确的修复是系统还原或修复安装。
虽然这不能直接归咎于 InnoSetup，因为它是由编写不佳的脚本造成的，但它足够令人沮丧和普遍，以至于当它的签名被添加到反恶意软件套件时我不会哭泣。有太多写得不好的例子散落在野副本/被太多人粘贴。
我花了很多时间来消除因卸载这些应用程序而造成的损害，并且对此感到非常厌倦。在可能的情况下，我现在在自卫中使用孤立的组件，这很有帮助。 Windows 文件保护在防止对系统文件的滥用行为方面也做得越来越好。
但总的来说，最好避免对应用程序中的脚本工具的任何依赖。尽管编写替代逻辑可能需要一些时间，但它们无论如何都不能像直接代码那样做得很好。