There is a lot of duplication of functions in the My.Computer.FileSystem
and System.IO.File
namespaces.
So what exactly is the difference between:
My.Computer.FileSystem.CopyFile(source, dest, True)
and:
System.IO.File.Copy(source, dest, True)
Is there a performance difference? What is everyone's opinion on which which has the edge on read-ability? I personally use the My.Computer
Namespace but that is just habit now.
Here's a difference that caused by app to malfunction:
My.Computer.FileSystem.WriteAllText inserts a 3 byte BOM (EF BB BF) at the beginning of the file, and system.io.file does not.
Thus, I replaced My.Computer.FileSystem.WriteAllText with system.io.file.WriteAllText and that fixed it.
My.* is simply a set of facade-pattern classes implemented for VB.NET that encompass common System.IO* (and other) operations. There is a very tiny performance hit since you're going through an extra layer of abstraction but you have to decide if it's worth optimizing for that. I would suggest using whichever way makes sense to you and others in your shop.
If you examine the code for
My.Computer.FileSystem.CopyFile
with .NET Reflector you will see that the method wraps many System.IO classes such as File and Directory and especially the File class' Copy, Move and Delete methods. Snippet:With regard to the
and
method, there is quite an important difference.
Using
a 'System.IO.IOException' will be thrown if the directory isn't empty. However, with
the default action is to go ahead and delete the file unless you include an addidional parameter
This is from this page
The other option is to specify DeleteDirectoryOption.ThrowIfDirectoryNonEmpty
There are also other differences, but this one, to me stands out a mile.
The
My
namespace is a VB.Net construct which is intended, in part, to be a bridge between VB6 and .Net APIs. These methods will tend to have VB6 semantics + look and feel.If you're a VB6 user transitioning to .Net I would use these methods as they will be closer to the behavior you are expecting. Otherwise I would stick with the standard .Net APIs of
System.IO.File.Copy
EDIT
Several people have questioned if I'm mistaking the
My
namespace for theMicrosoft.VisualBasic
namespace. I'm not. TheMy
namespace is a lot of things but one item it does is wrap certain calls into methods that forward intoMicrosoft.VisualBasic
. For example if you type the following code into a VB.net projectIt will result in the following set of events
MyProject.Computer.FileSystem.CopyFile
will be embedded in the applicationMyProject
andMyComputer
will be generated into the assemblyMyComputer
type simply derives fromMicrosoft.VisualBasic.Devices.Computer
FileSystem.CopyFile
method resolves down toFileSystemProxy.CopyFile
which simply forwards toFileSystem.CopyFile
Virtually nothing.
My.Computer
was added to VB as a more convenient and understandable abstraction layer to underlying functions. Some of it's methods add new functionality which in my opinion would be the only time you would use it overSystem.IO.File
.An example where
My.Computer
would add functionality overSystem.IO.File
is the Network.DownloadFile method, wherein it has the ability to show a dialog to the user:If you've already used
System.IO.File
in places I'd highly recommend against usingMy.Computer
over it for consistency reasons. Namely, don't go around mixing calls to methods inMy.Computer
andSystem.IO.File
, stick to one namespace!