Vb6 使用windows脚本运行时，特别是其中的FileSystemObject是一个好主意吗？

最近我被要求对VB6应用程序进行一些维护。这涉及到一些文件IO。我发现通过引用windows脚本主机和使用FileSystemObject提供的IO操作比VB6附带的IO操作要友好得多 但是，这会因为安全问题，或者因为脚本主机将在某些用户的计算机上被禁用而导致问题吗

---

更新（2012年8月20日）：自提出此问题以来，我们在3000名客户中三次遇到了无法正常工作的scrrun.dll问题。我们必须通过远程支持手动修复这些问题。似乎有时要归咎于病毒扫描商。

正如罗伯特·哈维（Robert Harvey）在评论中提到的，这在实践中通常不是问题。但是，

scrrun.dll

可能未安装或未在给定计算机上正确注册。在客户的机器上安装我们自己的VB6应用程序时，我们遇到了这两种情况

至于禁用脚本，我们实际上在其他应用程序（如Microsoft InfoPath）中遇到了这个问题，并通过将InfoPath表单（需要执行一些文件I/O）调出到使用WSH

FileSystemObject

的VB6 DLL来解决这个问题，因此，通过将该库与VB6结合使用，实际上可以解决脚本安全问题。据我所知，WSH安全设置专门应用于实际脚本，而不是恰好使用脚本运行时组件的程序

---

事实上，您可以并且仍然可以从VB6应用程序访问WSH组件，例如

FileSystemObject

。

VB中的文件IO总是有一些语法上的“奇怪之处”，这是因为它继承了Q/BASIC，但是如果您坚持直接读/写（避免行输入/写/获取），它的使用非常简单。 使用本机方法将比FSO更快，并避免任何依赖性问题，无论这些问题多么罕见

---

另一个需要考虑的问题是，如果要执行二进制文件IO，无论如何都必须使用本机方法，因为FSO是纯文本的。

我偶尔遇到客户机器，

FileSystemObject

无法工作，可能是因为偏执的IT部门以某种方式禁用了它。如果可能的话，我现在尝试避免使用

FileSystemObject

通常，您可以使用直接指向Windows API的本机VB6代码或API调用替换

FileSystemObject

。例如，Karl E Peterson的《卓越》中有一些完全用VB6编写的伟大对象

一些例子

• 将整个文本文件转换为字符串
• 目录是否存在
• 文件是否存在
• 用于通过子目录递归的文件
• 仅驱动器和目录的文件路径

---

我还没有看到你假设的例子在现实世界中成为一个实际问题。但是如果禁用WSH，肯定会阻止WSH脚本的执行。用现代语言重写应用程序是否可以被视为合理的维护？脚本运行时与WSH完全分离。不过，本机I/O语句可能比使用FSO强大得多。我见过病毒扫描程序禁用/干扰scrrun.dll。从内存来看，这是一个kapersky病毒扫描器+1，我也遇到过

FileSystemObject

无法工作的客户机器，可能是因为偏执狂departments@MarkJ：正如我在回答中提到的，禁用WSH不会阻止您在VB6应用程序中使用

FileSystemObject

，因为这些设置只影响您是否可以运行脚本。有趣的是，Microsoft（）的这篇文章似乎指出，禁用对

FileSystemObject

访问的具体方法是在计算机上注销

scrrun.dll

。似乎没有专门的设置或权限来打开或关闭它。对于我们自己的应用程序，

FileSystemObject

或

Dictionary

类的某些组件依赖于

scrrun.dll

，并且由于我们正试图逐步淘汰基于VB6的产品，我怀疑我们是否会重构它们以使用本机方法。如果

scrrun.dll

未注册，我们只需重新注册，如果有人要求，我们会解释我们的应用程序需要它。到目前为止，我们遇到的IT部门还没有多疑到告诉我们不；-）您是正确的，如果您选择禁用WSH，并且按照Microsoft认可的方式执行，则不会影响

FileSystemObject

。我们遇到了一些IT部门的客户，他们喜欢走得更远。这是罕见的，但它们是一个痛苦的解决办法。我们在全球范围内分发了数千份安装盘，很难让it部门与我们联系，更不用说注册DLL了。