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.
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.
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.
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
来源：https://stackoverflow.com/questions/2845797/is-using-the-windows-scripting-runtime-especially-the-filesystemobject-thereof