我们应该部署 scrrun.dll（Windows 脚本运行时）吗？

Question

我们的 VB6 应用程序在很大程度上依赖于 scrrun.dll（Windows 脚本宿主）的使用。直到一年前，我们还使用我们的安装程序来部署这个 dll。 Since the Windows Scripitng Host is supposed to be part of Windows我们从安装包中删除了dll。但是，有时会出现在他们的系统上具有非功能性 scrrun.dll 的客户，我们必须帮助他们重新安装或重新注册它。

那么，我们应该把 scrrun.dll 放回安装包吗？我们应该对安装进行一些检查吗？还是我们应该接受这样一个事实，即我们必须为一些客户提供实际支持以正确设置他们的系统？

Answer 1

Don't try to deploy these libraries as part of a normal setup.

Microsoft Scripting Runtime 必须通过使用 自解压 .exe 文件。对于提到的脚本运行时版本 在本文开头，分发它的唯一方法是 使用位于以下位置的完整自解压 .exe 文件 地点...

可能有些用户使用了较旧的反恶意软件套件，其中许多都试图禁用脚本。更有可能的是，一些用户设法破坏了他们的 Windows 安装，无论是他们自己还是通过使用未正确打包的应用程序来尝试包含这些库 - 并在卸载时盲目地将它们从系统中删除（咳咳 - Inno)。

所涉及的库已经定制了一段时间的代码。这就是为什么古老的 .CAB 文件很久以前就被“召回”了。它们没有一个副本可以在任何随机版本的 Windows 上运行，也没有任何现代版本的 Windows 的 redist 包。正确的修复方法是系统还原或修复安装。

虽然这不能直接归咎于 InnoSetup，因为它是由编写不当的脚本造成的，但它足够令人沮丧和普遍，以至于当它的签名被添加到反恶意软件套件时我不会哭泣。有太多写得不好的例子散落在野副本中/被太多人粘贴了。

我花了很多时间来消除因卸载这些应用程序而造成的损害，并且对此感到非常厌倦。在可能的情况下，我现在在自卫中使用孤立的组件，这很有帮助。 Windows File Protection 在防止对系统文件的滥用行为方面也做得更好。

但总的来说，您最好避免对应用程序中的脚本工具的任何依赖。尽管编写替代逻辑可能需要一些时间，但它们无论如何都不能像直接代码那样做得很好。