我们的VB6应用程序很大程度上依赖于scrrun.dll (Windows Scripting Host)的使用。直到一年前,我们还在使用安装程序部署这个dll。Since the Windows Scripitng Host is supposed to be part of Windows我们从安装包中删除了dll。然而,偶尔会有客户在他们的系统上有一个不起作用的scrrun.dll,我们必须帮助他们重新安装或重新注册。
那么,我们应该将scrrun.dll放回安装包中吗?我们应该在安装时执行一些检查吗?或者我们应该接受这样一个事实,即我们必须为一些客户提供实际支持,以正确地设置他们的系统?
发布于 2012-08-18 21:22:38
Don't try to deploy these libraries as part of a normal setup.
必须使用自解压.exe文件安装
Microsoft脚本运行时。对于本文开头提到的脚本运行时版本,分发它的唯一方法是使用位于以下位置的完整自解压.exe文件...
一些用户可能使用了较旧的反恶意软件套件,其中许多用户试图禁用脚本。然而,更有可能的是,一些用户设法破坏了他们的Windows安装,要么是他们自己,要么是通过使用不正确打包的应用程序来尝试包含这些库-并在卸载时盲目地将它们从系统中删除。
所涉及的库已经定制了一段时间。这就是为什么古老的.CAB文件很久以前就被“召回”了。它们没有打算在任何随机版本的Windows上运行的单一副本,也没有用于任何现代版本的Windows的redist包。正确的修复方法是系统还原或修复安装。
虽然这不能直接归咎于InnoSetup,因为它是写得不好的脚本的结果,但它足够令人沮丧和普遍,当它的签名被添加到反恶意软件套件时,我不会哭。太多的人随意复制/粘贴了太多写得很差的例子。
我花了大量的时间来消除卸载这些应用程序所造成的损害,并对此感到非常厌倦。在可能的情况下,我现在在自我保护中使用隔离的程序集,这很有帮助。Windows File Protection在防止对系统文件的滥用操作方面也做得越来越好。
但一般来说,在应用程序中避免对脚本工具的任何依赖要好得多。尽管编写替代逻辑可能需要一些时间,但它们所能做的并不像直接编写代码那样多。
https://stackoverflow.com/questions/12018602
复制相似问题