Is using the windows script host, especially the FileSystemObject hereof a good idea?

+4 A:

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.

Mike Spross 2010-05-17 01:46:06

+1 I too have encountered customer machines where `FileSystemObject` didn't work, presumably because of paranoid IT departments

MarkJ 2010-05-17 13:02:47

@MarkJ: As I mention in my answer, disabling WSH won't prevent you from using `FileSystemObject` in a VB6 application, since those settings only affect whether you can run scripts. Interestingly, this article from Microsoft (http://technet.microsoft.com/en-us/library/cc875829.aspx) seems to indicate that the way to disable access to `FileSystemObject` specifically is to simply unregister `scrrun.dll` on the machine. There doesn't seem to be a dedicated setting or permission to turn it on or off.

Mike Spross 2010-05-18 03:22:46

For our own application, certain components are dependent on `scrrun.dll` for either the `FileSystemObject` or `Dictionary` classes, and since we are trying to phase out the VB6-based products, I doubt we will refactor them to use native methods. In cases where `scrrun.dll` is unregistered, we simply re-register it, and if anyone asks, we explain that our application needs it. So far the IT departments we've encountered haven't been paranoid enough to tell us no ;-)

Mike Spross 2010-05-18 03:27:39

@Mike You are correct in that if you choose to disable WSH and you follow the approved Microsoft way to do that, it doesn't affect `FileSystemObject`. We have encountered a couple of customers with IT departments who like to go further. It's rare but they are a pain to sort out. We distribute thousands of copies of our installation disks worldwide - it can be hard to get the IT department to even talk to us, let alone register a DLL.

MarkJ 2010-05-18 09:07:34

+2 A:

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.

Alex K. 2010-05-17 11:46:58

+2 A:

I have occasionally encountered customer machines where FileSystemObject didn't work, presumably because of paranoid IT departments disabling it somehow. I now try to avoid FileSystemObject if possible.

You can usually replace the FileSystemObject with 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

Read an entire text file into a string.
Check whether a directory exists.
Check whether a file exists.
Search for files recursing through sub-directories.
Convert a file path to drive and directory only.
Get file date/time stamp

MarkJ 2010-05-17 13:08:35

ansaurus

tags:

views:

answers:

Is using the windows script host, especially the FileSystemObject hereof a good idea?

related questions