FileSystemObject and Distribution

[Unknown]

Anybody know when the FileSystemObject was introduced and whether or not
there is anything you need to distribute to end users of your application to
get access to it?

We have a Word macro as part of our application and I want to use the
FileSystemObject in it. We support Word 2000, XP, and 2003. I'm just
trying to confirm that I can use it, hopefully without having to distribute
any extra DLLs.

Thanks in advance for your comments.

 

[Jezebel]

The File System Object is part of Scripting Runtime, which has been around
since at least Windows 2000. It's not the version of Word that is your
concern, but the version of Windows. You're not allowed to distribute the
Scripting Runtime library to, and I think it wouldn't work, anyway.

However I suggest you look at the VB forum archives for any number of
threads on why you don't want to do this at all. For one thing, some network
security policies prevent its use (you can switch it off through IE's
Advanced tab). There are coding standards around that proscribe it too, on
the grounds that it is unreliable.

Which is no big deal, since there's nothing you can do with the FSO that you
can't easily do with ordinary VBA code. Using the FSO is a minor convenience
at best.

 

[Steve Yandl]

The scripting runtime (scrrun.dll) has been part of a default Windows
install since Win98 and beyond and Win2000 and beyond. It also gets
downloaded as part of the package by anyone downloaded Windows Script Host
(WSH) or vbScript and jScript from Microsoft. My understanding is that it
is also included with Office 2000 and beyond to insure availability.

Steve

 

[Steve Yandl]

One of the things I tend to use FileSystemObject for is to quickly check the
existence of specific files, folders, drives or shares before trying to do
something with them. It seems a lot easier than error handling. I also
tend to use it for minor manipulation of simple text files like ini or log
files but that is probably just habit on my part.

I'm fairly certain that if you restrict the scripting runtime through IE's
advanced tab, you're only impacting the running of scripting runtime when
script is being hosted by the browser. For example, a vbs or js file being
hosted by Windows Script Host is not impacted at all by IE settings. In
fact, an HTA file that allows html and scripts ignores IE settings. I
suspect that Office applications are likewise independent of IE settings and
only require a reference to the scripting run time to have access.

The rare user with a PC lacking the scripting runtime library, can download
for free at:
http://msdn.microsoft.com/library/default.asp?url=/downloads/list/webdev.asp

Steve

 

[Jezebel]

"Fairly certain" is not good enough if you're distributing something
professionally. And in this case wrong, also.

 

[Steve Yandl]

I don't distribute any of my projects professionally but I still wouldn't
want to share my work and have it not work for a friend or have my own stuff
fail to work for me under certain circumstances. What is the specific
setting under the IE settings advanced tab that will shut down the runtime
library. I have a few projects I'd like to test to see if I should spend a
bit of time updating previous work.

Steve

 

[Steve Yandl]

Jezebel,

I searched and searched but could not find any reference to a way IE
settings could interfere with my ability to use the FileSystemObject in
Word, other Office applications, script hosted by wsh or an hta file. I did
come across a few articles that others might find interesting:

http://office.microsoft.com/en-us/assistance/HA011379401033.aspx

http://pubs.logicalexpressions.com/Pub0009/LPMArticle.asp?ID=160

http://msdn.microsoft.com/library/chs/default.asp?url=/library/CHS/dntaloc/html/office09072000.asp

Steve

 

[Jezebel]

Try researching the topic in the main VB forum, where it is thrashed out in
detail about once a month. Or look at the security advisories relating to
it. For a while Norton was advocating deleting it entirely. Note that I'm
not taking a position either way on whether or not this is appropriate; just
observing that some organisation DO in fact disable scripting completely.

And since, in any case, the convenience of using the FSO is really pretty
minor, why bother? In any case, if error-handling is too much trouble for
your style of programming, concerns about reliability are moot anyway.

 

[Steve Yandl]

Jezebel,

I think we agree more than we disagree. It made you a bit angry that I
challenged any of your statements so you took a few cheap shots and I shot
back. The FileSystemObject can be simpler and quicker than other techniques
for a few select tasks but it's probably best avoided for solutions that
will be distributed to unknown recipients; on that, we agree. I'm not sure
I could go so far as suggesting that the person who posed the original
question in this thread should find an alternate approach though.

You stated that I was wrong claiming that security settings in IE would not
kill the ability to use FileSystemObject in Word or other Office
applications. I suspect you discovered that I was correct(if I'm wrong,
post a link to a specific example in the VB forum or anywhere else). Some
organizations do remove scrrun.dll and take other measures to prevent
problems with malicious scripts but that isn't the same as changing a
setting in IE. There is a reason that sccrun.dll has been included in
Office installations since Office2000 and while there may be reasons for
using other techniques the option is there for the taking.

Steve

 

[Jezebel]

heated agreement perhaps? I was neither angry nor taking cheap shots, just
concerned that you are misleading the OP by posting assertions that are
clearly beyond your competence.

 

[Steve Yandl]

OK, so you're saying I'm incompetent. That may be the case I suppose.

Please provide the setting in IE that you claim prevents use of the
FileSystemObject in VBA.

Steve

 

[Steve Yandl]

I've seen the advice to use "regsvr32 scrrun.dll /u" to disable
FileSystemObject but if an organization deletes it entirely as you claim
Norton advocated at some point in time, how are they able to continue
getting Microsoft updates?
http://support.microsoft.com/?scid=kb;en-us;836936
Seems like it would be quite a bother to have to download and install
scrrun.dll each time MS posted a new security update that needed to be
downloaded.

I may not be competent to discuss these issues but it seems to me that an
organization where they get rid of scripting runtime might be creating as
many security issues as they resolve. In any case, I suspect that most
security conscious organizations have left scrrun.dll in place on PCs and at
most have unregistered the dll (which would be an issue for any VBA use of
FileSystemObject, I admit).

Steve

 

[Unknown]

The reason I want to use the FileSystemObject to read text files is because
we need to support Unicode text files. The FileSystemObject supports
reading Unicode text files nicely. I haven't been able to get the standard
Open, Input, Line Input stuff to work with Unicode text files.

I've seen others suggest that I read the file as a binary file and then do
the conversion, but I'd rather not go through that hassle when the
FileSystemObject works very well.

 

[Steve Yandl]

As you can probably tell from reading my comments through this thread, I see
some advantage to using the FileSystemObject myself. I don't think you have
to worry about availability since scrrun.dll is distbibuted with Win98SE and
beyond, Win2000 and beyond, IE5 and beyond, Office 2000 and beyond, plus all
versions of WSH, vbs, and js.

Of course, you've probably also seen Jezebel's comments suggesting that I
was commenting on matters clearly beyond my level of competence. She might
be right; the best I can do is reference MSKB articles and articles by Word
MVPs; Jezebel is able to share the fact that the experts in VB forums
regularly thrash the concept of using FileSystemObject. Jezebel is so
obviously smarter than me, I dare not dispute her opinion!!!!!

Steve

 

[Unknown]

Jezebel needs to lighten up.

As you can probably tell from reading my comments through this thread, I
see some advantage to using the FileSystemObject myself. I don't think
you have to worry about availability since scrrun.dll is distbibuted with
Win98SE and beyond, Win2000 and beyond, IE5 and beyond, Office 2000 and
beyond, plus all versions of WSH, vbs, and js.

Of course, you've probably also seen Jezebel's comments suggesting that I
was commenting on matters clearly beyond my level of competence. She
might be right; the best I can do is reference MSKB articles and articles
by Word MVPs; Jezebel is able to share the fact that the experts in VB
forums regularly thrash the concept of using FileSystemObject. Jezebel is
so obviously smarter than me, I dare not dispute her opinion!!!!!

Steve

 

[Steve Yandl]

I reacted badly to her comments and I apologize for that.

I've seen plenty of her posts and she does have far more expertise in VBA
than I do. However, your question was about being certain the
FileSystemObject would be available and that is something I felt competent
to answer. I do a fair amount of scripts and knew that the scripting
runtime is available on most PCs, and that security settings on scripts made
in IE only affect scripts hosted by the browser and if a user is able to run
Windows update you can be confident that the user has not unregistered the
library.

Steve