部署 – 我们应该部署scrrun.dll(Windows Scripting Runtime)吗

发布时间：2020-12-14 03:52:39 所属栏目：Windows 来源：网络整理

导读：我们的VB6应用程序在很大程度上依赖于scrrun.dll( Windows Scripting Host)的使用.直到一年前,我们还使用安装程序部署了这个dll. Since the Windows Scripitng Host is supposed to be part of Windows我们从安装包中删除了dll.但是,偶尔会在其系统上使用非

我们的VB6应用程序在很大程度上依赖于scrrun.dll( Windows Scripting Host)的使用.直到一年前,我们还使用安装程序部署了这个dll. Since the Windows Scripitng Host is supposed to be part of Windows我们从安装包中删除了dll.但是,偶尔会在其系统上使用非功能性scrrun.dll的客户,我们必须帮助他们重新安装或重新注册.

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

解决方法

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

Microsoft Scripting Runtime must be installed through the use of a
self-extracting .exe file. For versions of Scripting Runtime mentioned
at the beginning of this article,the only way to distribute it is to
use the complete self extracting .exe file located at the following
locations…

有些用户可能会使用较旧的反恶意软件套件,其中许多套件试图禁用脚本.更有可能的是,有些用户设法破坏了他们的Windows安装,无论是他们自己还是使用不正确打包的应用程序试图包含这些库 – 并在卸载时盲目地从系统中删除它们(咳嗽,咳嗽 – Inno).

所涉及的图书馆已经定制了一段时间的代码.这就是古代.CAB文件很久以前被“召回”的原因.没有任何一个副本可以在任何随机版本的Windows上运行,并且没有适用于任何现代版本Windows的redist包.正确的修复是系统还原或修复安装.

虽然这不能直接归咎于InnoSetup,因为它是由于编写得不好的脚本造成的,但它足够令人沮丧且足够常见,以至于当其签名被添加到反恶意软件套件时我不会哭.在太多人的野外复制/粘贴中,有太多写得不好的例子.

我花了很多时间来解除因卸载这些应用程序而造成的损害,并且已经非常厌倦了它.在可能的情况下,我现在使用隔离组件进行自卫,这有很大帮助. Windows File Protection在防止系统文件的滥用行为方面也越来越好.

但总的来说,最好避免在应用程序中依赖脚本工具.尽管编写替代逻辑可能还需要一些时间,但他们无论如何都可以做到直接代码.

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!