Differance on FileSystemObject & TextStream when upgrading version

[Mr. X.]

Hello.
I upgrade my code from VB 6 -> VB.NET 2005 (Visual studio).
The following code was great for VB 6 :
============================
dim fs as FileSystemObject = new ...
dim ts as TextStream
dim file_name as string

.....

file_name = "a_file.txt"
ts = fs.CreateTextFile(file_name, false)
ts = nothing
**** the following line in VB.NET only, and not on VB.6 ***
ts.close()
****

When trying to delete the file by : fs.deleteFile(file_name)
it works on VB.6, but on VB.NET the remarked line (ts.close() ) is
necessary, otherwise I got "permission denied exception"

Why should I have the ts.close file on VB.NET, since I only create the file
and not open it for output ?

Is there any problem on VB.6, if I don't add the remarked line : ts.close()
?

Thanks

 

[Andrew Morton]

I upgrade my code from VB 6 -> VB.NET 2005 (Visual studio).

The general opinion in this newsgroup seems to be that the best way is to
rewrite the code, not upgrade.

The following code was great for VB 6 :
file_name = "a_file.txt"
ts = fs.CreateTextFile(file_name, false)
ts = nothing
**** the following line in VB.NET only, and not on VB.6 ***
ts.close()
****

When trying to delete the file by : fs.deleteFile(file_name)
it works on VB.6, but on VB.NET the remarked line (ts.close() ) is
necessary, otherwise I got "permission denied exception"

Why should I have the ts.close file on VB.NET, since I only create
the file and not open it for output ?

In VB6, the line ts=nothing might be immediately closing the file for you.
In VB.NET, it doesn't dispose of the object immediately. IMHO, setting it to
nothing and hoping for the side-effect of closing the file is wrong in the
first place, you should always explicitly close the file.

Also, see System.IO.File.Create.

Andrew

 

[Phill W.]

I upgrade my code from VB 6 -> VB.NET 2005 (Visual studio).
The following code was great for VB 6 :
============================
dim fs as FileSystemObject = new ...

"great"? Debatable and, indeed, much debated to date.
I'm definitely in the "The FSO is awful" camp.

dim ts as TextStream
dim file_name as string
....
file_name = "a_file.txt"
ts = fs.CreateTextFile(file_name, false)
ts = nothing
**** the following line in VB.NET only, and not on VB.6 ***
ts.close()
****

When trying to delete the file by : fs.deleteFile(file_name)
it works on VB.6, but on VB.NET the remarked line (ts.close() ) is
necessary, otherwise I got "permission denied exception"

Which is pretty much what you'd expect, because the the file is being
held open by your application. Strictly speaking, the VB6 version
should Close the TextStream object but, because of the way objects are
handle in VB6, it does it /for/ you.

Why should I have the ts.close file on VB.NET, since I only create the file
and not open it for output ?

The handling of COM (and, indeed, all) objects is *different* in .Net.

Set an object to Nothing in VB6 and it gets trashed (and, in this case,
the file gets closed) immediately.
Set an object to Nothing in VB.Net and /all/ you're doing is declaring
to the run-time that you no longer care what happens to the object, or
when.

Garbage Collection will take it away and destroy it "some time" later,
but you have little or no idea when. BTW, don't be tempted to try and
"kick" GC into life yourself; you /might/ solve this one problem, but
your application will suffer overall.

This is what the IDisposable Interface is supposed to address, giving
you a hook (the Dispose method) within which to put "clean-up" code like
this.

Is there any problem on VB.6, if I don't add the remarked line : ts.close()

It works, but it's far, far /clearer/ if you explicitly Close everything
you Open.

HTH,
Phill W.

 

[Family Tree Mike]

Hello.
I upgrade my code from VB 6 -> VB.NET 2005 (Visual studio).
The following code was great for VB 6 :
============================
dim fs as FileSystemObject = new ...
dim ts as TextStream
dim file_name as string

.....

file_name = "a_file.txt"
ts = fs.CreateTextFile(file_name, false)
ts = nothing
**** the following line in VB.NET only, and not on VB.6 ***
ts.close()
****

When trying to delete the file by : fs.deleteFile(file_name)
it works on VB.6, but on VB.NET the remarked line (ts.close() ) is
necessary, otherwise I got "permission denied exception"

Why should I have the ts.close file on VB.NET, since I only create the file
and not open it for output ?

Is there any problem on VB.6, if I don't add the remarked line : ts.close()
?

Thanks

From MSDN (http://msdn.microsoft.com/en-us/library/5t9b5c0c(VS.85).aspx),
there is an example which implies at least to me that you should have used
the close().

Mike

 

[Lloyd Sheen]

Hello.
I upgrade my code from VB 6 -> VB.NET 2005 (Visual studio).
The following code was great for VB 6 :
============================
dim fs as FileSystemObject = new ...
dim ts as TextStream
dim file_name as string

....

file_name = "a_file.txt"
ts = fs.CreateTextFile(file_name, false)
ts = nothing
**** the following line in VB.NET only, and not on VB.6 ***
ts.close()
****

When trying to delete the file by : fs.deleteFile(file_name)
it works on VB.6, but on VB.NET the remarked line (ts.close() ) is
necessary, otherwise I got "permission denied exception"

Why should I have the ts.close file on VB.NET, since I only create the
file and not open it for output ?

Is there any problem on VB.6, if I don't add the remarked line :
ts.close() ?

Thanks

Since you are now using VB.NET I would suggest getting rid of
FileSystemObject and investigating the My namespace. It has many functions
for dealing with the file system.

http://www.code-magazine.com/Article.aspx?quickid=0409031

http://msdn.microsoft.com/en-us/vbasic/ms789188.aspx

LS

 

[Herfried K. Wagner [MVP]]

The handling of COM (and, indeed, all) objects is *different* in .Net.

Set an object to Nothing in VB6 and it gets trashed (and, in this case,
the file gets closed) immediately.

More specifically: Setting a reference to 'Nothing' will increment the
reference count of the object previously referenced by the reference. If
the reference count is zero, the object will be destroyed immediately. This
is not necessarily the case if the object is still referenced by other
references.

 

[Herfried K. Wagner [MVP]]

Also, take a look at the System.IO namespace. This namespace has file and
directory handling classes. This will have the additional benefit of
helping you convert to or from C# code, which doesn't have the My
namespace.

Well, the FSO can be used in C# too, can't it? In addition, I have rarely
seen the necessity to convert a whole project from one .NET programming
language to another.

BTW, I consider using 'System.IO' or 'My.Computer.*' more clean than the
COM-based FSO (which is not part of 'My'!).

 

[Family Tree Mike]

More specifically: Setting a reference to 'Nothing' will increment the
reference count of the object previously referenced by the reference. If
the reference count is zero, the object will be destroyed immediately.
This is not necessarily the case if the object is still referenced by
other references.

I think you meant "decrement" the reference count.

 

[Herfried K. Wagner [MVP]]

I think you meant "decrement" the reference count.

Sorry, you are absolutely right!

 

[Onur Güzel]

Sorry, you are absolutely right!

Plus, to make an little addition, for COM-based objects, setting COM
object to Nothing is not enough alone, it's also recommended to call:
"Marshal.ReleaseComObject" to decrement the reference count of the
supplied runtime callable wrapper. In that case it would be reasonable
to use native managed classes such as 'System.IO' and 'My.Computer' as
prevously being said.

Onur Güzel

 

[Herfried K. Wagner [MVP]]

Plus, to make an little addition, for COM-based objects, setting COM
object to Nothing is not enough alone, it's also recommended to call:
"Marshal.ReleaseComObject" to decrement the reference count of the
supplied runtime callable wrapper. In that case it would be reasonable
to use native managed classes such as 'System.IO' and 'My.Computer' as
prevously being said.

I'd recommend this approach too because adding the 'ReleaseComObject' stuff
is not much less complicated than rewriting the code to use .NET's class
library.