‘scripting’ and File System object (VBA/Excel 2000)

Topic

New Reply

Is the File System object (Scripting.FileSystemObject) related in some way to the Windows Scripting Host? Should I avoid its use if I expect my users to avoid WSH for security reasons?

Reply | Quote

Replies

I guess the answers are Yes, Yes. But I’m not completely sure.

Reply | Quote

The FileSystem Object is part of Microsoft’s scripting technology, but is all contained with a DLL (sccrun.dll) and is not intrinsically linked with the Windows Scripting Host. It is possible to disable WSH but retain sccrun.dll on your system just like any other DLL. You can then access it via VB or VBA etc.

Andrew C

Reply | Quote

Another way to think about this is: all scripts need a host. Internet Explorer can be the host; Outlook Forms can be the host; ASP can be the host; a VBA-aware application can be the host; or the Windows Script Host can be the host. Removing WScript.exe, and the WScript.Object entries in the Registry, will prevent any script from being hosted by the Windows Script Host, and will limit the potential access scripts have to the system from other hosts. But it should leave Scripting.FileSystemObject intact. Of course, it’s possible that someone will remove that, too…

The alternatives to the FileSystemObject include the rudimentary Basic commands, and a large family of Windows API calls. I believe that one of my seldom-used VBA books came with a class library that nicely wrapped these calls, or maybe I saw it (or a link to it) posted here. It’s definitely one of those things to wrap once and reuse often, to avoid the crashes that can occur with inadequately debugged DLL calls.

Reply | Quote

Not really pertinent to Excel 2000, but also worth mentioning is that in the .NET Framework, properties and methods previously available via FileSystemObject, have been folded into the System.IO namespace, making them easily available.

Reply | Quote