最近我被要求对 VB6 应用程序进行一些维护。这涉及到一些文件IO。我发现通过引用 Windows 脚本宿主并使用 FileSystemObject 提供的 IO 操作比 VB6 附带的 IO 操作友好得多。
但这是否会因安全问题或脚本宿主在某些用户计算机上被禁用而导致问题？
更新（2012年8月20日）：自从提出这个问题以来，我们已经在3000个客户中遇到了3次scrrun.dll无法运行的问题。我们必须通过远程支持手动修复这些问题。有时病毒扫描程序似乎是罪魁祸首。
Recently I have been asked to do some maintenance on a VB6 application. This involves some file IO. I find the IO operations offered by referencing the windows script host and using the FileSystemObject a lot friendlier than the IO operations that come with VB6.
But will this cause problems because of security issues, or because of the fact that the script host will be disabled on some users' computers?
Update (aug 20, 2012): Since asking this question we have encountered the problem of a non functional scrrun.dll three times among 3000 customers. We had to fix these manually through remote support. It seems that sometimes a virusscanner is to blame.
发布评论
评论（3）
正如罗伯特·哈维在他的评论中提到的，这在实践中通常不是问题。不过，
scrrun.dll可能未在给定计算机上安装或未正确注册。当我们在客户的机器上安装我们自己的 VB6 应用程序时，我们遇到过这两种情况。至于禁用脚本，我们实际上在其他应用程序（例如 Microsoft InfoPath）中遇到过这个问题，并通过让 InfoPath 表单（需要执行一些文件 I/O）调用 VB6 来解决这个问题使用 WSH
FileSystemObject的 DLL，因此，如果有的话，您实际上可以通过将该库与 VB6 结合使用来解决脚本安全问题。据我所知，WSH 安全设置专门适用于实际脚本，而不适用于碰巧使用脚本运行时组件的程序。事实上，您可以完全禁用计算机上的 Windows Scipt Host ，并且仍然可以从 VB6 应用程序访问 WSH 组件，例如
FileSystemObject。As Robert Harvey mentioned in his comment, this isn't usually a problem in practice. It's possible that the
scrrun.dllmay either not be installed or is not registered correctly on a given machine though. We've encountered both scenarios when installing our own VB6 application on customer's machines.As for scripting being disabled, we've actually run into this problem with other applications (such as Microsoft InfoPath), and got around the issue by having the InfoPath form (which needed to do some file I/O) call out to a VB6 DLL that used the WSH
FileSystemObject, so if anything, you can actually work around script security problems by using the library in conjunction with VB6. As far as I know, WSH security settings apply specifically to actual scripts, not to programs that happen to use components from the scripting runtime.In fact, you can completely disable the Windows Scipt Host on your machine, and still access the WSH components, such as
FileSystemObject, from a VB6 application.由于继承自 Q/BASIC，VB 中的文件 IO 始终有一点语法“奇怪”，但如果您坚持直接读/写（避免行输入/写/获取），则使用起来很简单。
使用本机方法将比 FSO 更快，并且可以避免任何依赖性问题，无论它们有多罕见。
另一个考虑因素是，如果您想执行二进制文件 IO，则无论如何都必须使用本机方法，因为 FSO 仅是文本。
File IO in VB has always had a bit of syntactic "oddness" due to its inheritance from Q/BASIC but its simple to use if you stick to direct read/writes (avoiding Line Input/Write/Get).
Using the native methods will be faster than the FSO and avoid any dependency issues, no matter how rare they may be.
Another consideration is that if you want to perform binary file IO you will have to use the native methods anyway as the FSO is text only.
我偶尔会遇到
FileSystemObject无法工作的客户计算机，大概是因为偏执的 IT 部门以某种方式禁用了它。如果可能的话，我现在尝试避免FileSystemObject。您通常可以将
FileSystemObject替换为本机 VB6 代码或直接对 Windows API 的 API 调用。例如，Karl E Peterson 的优秀 VB6 网站 有一些完全用 VB6 编写的很棒的对象。一些示例
I have occasionally encountered customer machines where
FileSystemObjectdidn't work, presumably because of paranoid IT departments disabling it somehow. I now try to avoidFileSystemObjectif possible.You can usually replace the
FileSystemObjectwith native VB6 code or API calls direct to the Windows API. For example Karl E Peterson's excellent VB6 website has some great objects written entirely in VB6.Some examples