|
code
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
Downside to using FileSystemObject?Hi,
I remember some discussion here a couple of years ago about the FileSystemObject. Some of the more experienced VB6 programmers had a very negative opinion of it. I just found out that I may need to use it in a project at work; I am trying to remember what the downsides mentioned were so I can avoid any potential pitfall. Does the FSO suffer from poor performance? Is it an issue with deploying applications relying on it? Thanks for your advice. "Mike" <nospam@please.com> wrote in message Yes; it's notoriously slownews:%23MvF1F10FHA.2212@TK2MSFTNGP15.phx.gbl > Hi, > > I remember some discussion here a couple of years ago about the > FileSystemObject. Some of the more experienced VB6 programmers had a > very negative opinion of it. I just found out that I may need to use > it in a project at work; I am trying to remember what the downsides > mentioned were so I can avoid any potential pitfall. Does the FSO > suffer from poor performance? > Is it an issue with deploying Yes; there are several versions floating around they aren't all compatible> applications relying on it? with each other. Those are the two main strikes against it. There are also places where it is disabled to help avoid virus propagation. The bottom line for me is that it is an extra dependency to deal with when it's pretty easy to eliminate it with some VB code and API work and lots of examples are available. It doesn't provide anything that can't be done better and/or faster in other ways. -- Reply to the group so all can participate VB.Net: "Fool me once..." Bob Butler wrote:
> "Mike" <nospam@please.com> wrote ... [VBnet File API] Performance Comparison - FSO vs API>> Does the FSO suffer from poor performance? > > Yes; it's notoriously slow http://vbnet.mvps.org/code/fileapi/fsoapicompare.htm >> Is it an issue with deploying And all that, too!>> applications relying on it? > > Yes; there are several versions floating around they aren't all > compatible with each other. > > Those are the two main strikes against it. There are also places > where it is disabled to help avoid virus propagation. The bottom > line for me is that it is an extra dependency to deal with when it's > pretty easy to eliminate it with some VB code and API work and lots > of examples are available. It doesn't provide anything that can't be > done better and/or faster in other ways. If you like the FileSystemObject's object model, then you might try
this library:" http://www.killervb.com/FileSystemLib.aspx On 17 Oct 2005 14:23:13 -0700, "Chris Dunaway" <dunaw***@gmail.com> Phew - First time I've seen that - it looks very interestingwrote: >If you like the FileSystemObject's object model, then you might try >this library:" >http://www.killervb.com/FileSystemLib.aspx thanks Chris FSO is the spawn of Satan. Every time you use it, a butterfly dies.
Negative enough? <g> Show quoteHide quote "Mike" <nospam@please.com> wrote in message news:#MvF1F10FHA.2212@TK2MSFTNGP15.phx.gbl... > Hi, > > I remember some discussion here a couple of years ago about the > FileSystemObject. Some of the more experienced VB6 programmers had a very > negative opinion of it. I just found out that I may need to use it in a > project at work; I am trying to remember what the downsides mentioned were > so I can avoid any potential pitfall. Does the FSO suffer from poor > performance? Is it an issue with deploying applications relying on it? > > Thanks for your advice. > > On Mon, 17 Oct 2005 12:32:03 -0700, "Mike" <nospam@please.com> wrote: ¤ Hi,¤ ¤ I remember some discussion here a couple of years ago about the ¤ FileSystemObject. Some of the more experienced VB6 programmers had a very ¤ negative opinion of it. I just found out that I may need to use it in a ¤ project at work; I am trying to remember what the downsides mentioned were ¤ so I can avoid any potential pitfall. Does the FSO suffer from poor ¤ performance? Is it an issue with deploying applications relying on it? In general it's not on par with respect to performance but in some situations it's acceptable if the file operations are not repetitive. I use it but typically only in ASP applications where there is no native language file i/o and I don't have time to develop an ActiveX DLL to perform this function. I've seen some versioning issues although I've never encountered any myself. You're more likely to encounter issues if you're distributing your app to home or external users, where system configurations can vary widely. If the environment you are distributing to is under a fair amount of control then versioning will probably not be an issue. Paul ~~~~ Microsoft MVP (Visual Basic) |
|||||||||||||||||||||||