What exactly is the difference between My.Computer.FileSystem and System.IO.File

Question

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.

Site

Answer 1

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:

'lots of other code snipped out for brevity and to show the use of System.IO classes...

Directory.CreateDirectory(FileSystem.GetParentPath(str))

   'snip

    If 
       ' snip
    Else
        File.Delete(str)
        File.Move(path, str)
    End If
Else
    File.Move(path, str)
End If
End Sub

Backsword

Thanks for the answer. It's just me 'in my shop' so I can decide on what I like, but I was kind of interested in people's preferences. – Site

JIT compilation makes even the "tiny performance hit" even less likely to be noticeable. I don't use the My class very much just for consistency reasons, but there's absolutely nothing wrong with using it if you find it convenient. That's the whole point, to speed development in common cases. – Meso

@Cody: Agreed on all counts. I edited and added the qualifier very to tiny per your feedback. – Backsword

Answer 2

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 over System.IO.File.

An example where My.Computer would add functionality over System.IO.File is the Network.DownloadFile method, wherein it has the ability to show a dialog to the user:

If showUI is set to True, a dialog box appears that shows the progress of the operation; the dialog box contains a Cancel button that can be used to cancel the operation. The dialog box is not modal, and therefore does not block user input to other windows in the program.

If you've already used System.IO.File in places I'd highly recommend against using My.Computer over it for consistency reasons. Namely, don't go around mixing calls to methods in My.Computer and System.IO.File, stick to one namespace!

Roughspoken

“My.Computer was added to VB for beginners” – nonsense. That was never the stated use. Rather, it’s a convenience layer and nothing speaks against using it. It’s a bit unfortunate that some functionality is exactly duplicated though. – Fourthclass

The fact that it abstracts functions for the user makes it a key item for beginner usage. It's not just a convenience layer so much as it provides extra functionality for certain methods over System.IO.*. I never meant my statement about beginners to be such a direct statement as I wrote it. – Roughspoken

See my edited answer, hope this conveys the point a little bit better. – Roughspoken

"virtually nothing" except that My.Computer.FileSystem.WriteAllText inserts a 3 byte BOM at the beginning of the file, and system.io.file does not. – Volplane

Answer 3

With regard to the

System.IO.Directory.Delete

and

FileSystem.DeleteDirectory 

method, there is quite an important difference.

Using

System.IO.Directory.Delete

a 'System.IO.IOException' will be thrown if the directory isn't empty. However, with

FileSystem.DeleteDirectory

the default action is to go ahead and delete the file unless you include an addidional parameter

This is from this page

Public Shared Sub DeleteDirectory ( directory As String, onDirectoryNotEmpty As DeleteDirectoryOption )

Parameters directory

Type: System.String Directory to be deleted. onDirectoryNotEmpty

Type: Microsoft.VisualBasic.FileIO.DeleteDirectoryOption Specifies what should be done when a directory that is to be deleted contains files or directories. Default is DeleteDirectoryOption.DeleteAllContents.

The other option is to specify DeleteDirectoryOption.ThrowIfDirectoryNonEmpty

There are also other differences, but this one, to me stands out a mile.

Perri

Answer 4

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 the Microsoft.VisualBasic namespace. I'm not. The My namespace is a lot of things but one item it does is wrap certain calls into methods that forward into Microsoft.VisualBasic. For example if you type the following code into a VB.net project

My.Computer.FileSystem.CopyFile(source, dest)

It will result in the following set of events

• A call to MyProject.Computer.FileSystem.CopyFile will be embedded in the application
• The types MyProject and MyComputer will be generated into the assembly
• The MyComputer type simply derives from Microsoft.VisualBasic.Devices.Computer
• Hence the FileSystem.CopyFile method resolves down to FileSystemProxy.CopyFile which simply forwards to FileSystem.CopyFile

Anastrophe

“to be a bridge between VB6 and .Net APIs” – really? I think you’re confusing this with the Microsoft.VisualBasic namespace. Two things speak against your theory: ① the namespaces was added in later versions of VB.NET, and ② it doesn’t replicate the VB6 functionality particularly closely (except for My.Forms). – Fourthclass

@Konrad I'm fairly certain I'm correct on this. Under the hood the My.Computer.FileSystem calls get generated into the target assembly and they forward to Microsoft.VisualBasic. You can verify this with reflector – Anastrophe

@Jared Even string comparison ("a" = "b") emits code that relies on Microsoft.VisualBasic, that’s not an argument. – Fourthclass

@Konrad see my editted answer. Uses of My.Computer.FileSystem do forward to Microsoft.VisualBasic.FileSystem which in part is intended as a compatibility layer for VB6 users. – Anastrophe

@Jared Doesn’t My.Computer.FileSystem really forward to Microsoft.VisualBasic.FileIO.FileSystem, which is a distinct class from Microsoft.VisualBasic.FileSystem? Can’t verify this now but this is the way I remember it and from the MSDN this makes more sense. The latter is indeed part of the compatibility layer while the former is a later introduction as part of the My namespace support layer. – Fourthclass

@Konrad, those 3 types confuse me all the time. Give me a sec – Anastrophe

@Konrad yes the My.Computer.FileSystem eventually forwards into M.VB.FileIO.FileSystem. I was under the impression that both types though were a part of the compatibility layer. The FileIO.FileSystem methods in particular – Anastrophe

Answer 5

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.

Volplane

Answer 6

With System.IO.File.Delete there is indeed a difference as compared to My.Computer.FileSystem.DeleteFile:

My.Computer.FileSystem.DeleteFile(a_file) throws a FileNotFoundException if a_file doesn't exist, whereas System.IO.File.Delete(a_file) does not.

System.IO.File.Delete only throws a DirectoryNotFoundException if the path included in a_file does not exist.

Dillingham