Differance on FileSystemObject & TextStream when upgrading version

  • Thread starter Thread starter Mr. X.
  • Start date Start date
M

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 :)
 
Mr. X. said:
I upgrade my code from VB 6 -> VB.NET 2005 (Visual studio).
Click to expand...

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 ?
Click to expand...

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
 
Mr. X. said:
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 ...
Click to expand...

"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()
****
Click to expand...
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"
Click to expand...

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 ?
Click to expand...

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()
Click to expand...

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

HTH,
Phill W.
 
Mr. X. said:
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 :)
Click to expand...

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
 
Mr. X. said:
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 :)
Click to expand...

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
 
Phill W. said:
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.
Click to expand...

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.
 
Michael D. Ober said:
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.
Click to expand...

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'!).
 
Herfried K. Wagner said:
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.
Click to expand...


I think you meant "decrement" the reference count.
 
Sorry, you are absolutely right!
Click to expand...

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
 
Onur Güzel said:
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.
Click to expand...

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.
 
Back
Top