Is using the windows scripting runtime, especially the FileSystemObject thereof a good idea?

Question

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.

Answer 1

As Robert Harvey mentioned in his comment, this isn't usually a problem in practice. It's possible that the scrrun.dll may 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.