is there any disadvantages using Filesystemobject for file operations? which is better .net framework or filesystemobject
Printable View
is there any disadvantages using Filesystemobject for file operations? which is better .net framework or filesystemobject
I think this article sums it up nicely:)
I recently explored this decision, in the end I'm going with Filesystem object.
Posters here are what got me to look into the .net way and although it seems more robust i still feel i have more control over what i'm trying to accomplish with my file then i do with the .net method.
Maybe a future project i'll use the .net way but at the moment i'm sticking with old tried and true way. My familiarity may have allot to do with my decision but at the end of the day i can't help feel that i'm much more in control over my data.
my 2 cents.
Once you learn the .NET ways you will rarely go back.
There are more benefits to using the .NET objects over the legacy MS.VB objects.
My 3 cents :D
Indeed. For example, by learning how to use the Stream/Binary writer, you do not only get the knowledge on how to write to filestreams, but then you can apply the exact same knowledge to write to any stream, a networkstream for example.
My 4 cents:D
You can do anything you want with any file down to the byte using .NET file I/O. There is no advantage to using unmanaged code for I/O.Quote:
Originally Posted by sytto
The classes in the Stsrem.IO namespace are what you should be looking at first. There is also the My.Computer.FileSystem object. Many of the methods of the My.Computer.FileSystem object wrap members of classes in the System.IO namespace. For instance, My.Computer.FileSystem.FileExists calls IO.File.Exists and My.Computer.FileSystem.RenameFile calls IO.File.Move. Many others use the Windows Shell, allowing you to display the same progress dialogues used by Windows Explorer.
Where i ran into uncertainty was when i wanted to get something from my structure at say record 35.
Obviously I've left some code out,
fileopen...
FileGet(freef, mystruct, 35)
myvar = data.item
fileclose(freef)
Super simple, no fuss, no muss, straight to exactly what i want.
How do you do this the .net way?
I've never used FileGet so I don't know exactly what that code does. That said, the documentation for the FileGet function states:and provides a link. When you follow that link you get a list of tasks you might want to perform and a How To link for each one. Further, you also have the System.IO namespace with classes like BinaryReader etc.Quote:
Originally Posted by MSDN
That code basically does this:
*open file*
fileopen...
*get record 35*
FileGet(freef, mystruct, 35)
*get the item of data i want from record 35 and put it into a variable*
myvar = data.item
*close the file*
fileclose(freef)
How you do that the .net way has eluded me.
What do you actually mean by 'record 35'? Sounds like some database stuff:confused:
No database stuff. I create a structure and enter data into it. Then if a persons Record# is 45 i can go straight to record 45 and get their name for example using the code above.
I dug up a MS example below.
Code:
Structure Person
Public ID As Integer
Public Name As String
End Structure
Sub WriteData()
Dim PatientRecord As Person
Dim recordNumber As Integer
' Open file for random access.
FileOpen(1, "C:\TESTFILE.txt", OpenMode.Binary)
' Loop 5 times.
For recordNumber = 1 To 5
' Define ID.
PatientRecord.ID = recordNumber
' Create a string.
PatientRecord.Name = "Name " & recordNumber
' Write record to file.
FilePut(1, PatientRecord)
Next recordNumber
FileClose(1)
End Sub
Sounds like a better way to do all that is serializing/deserializing the structures using XML or binary serialization.
How do code to go straight to a record# and get something from the structure?
to be honest, I have no idea how to do that, as I've never needed to. Being that file operations are relatively slow, I personally dont think you would gain anything if you where able to read and deserialize a only a specific part of the file, it would be better to deserialize the entire file into a collection of the structure at startup, then perform all actions on the collection, and deserialize upon closing the application.
I think I'm seeing why MS actually never pulled the old style, it seems it's better in certain situations.
Here is a scenario, i have person come to me and and say i'm station 45 and ask what was my time and amount for item whatever.
The couple simple lines of code i use along with variables gives me the answer as it instantly goes to record 45, gets time and amount.
If someone could tell me how to do what i do with Filesystemobject in .net i would gladly explore the .net option further.
I respect your opinions on what you think about Filesystem Object Vs .NET methods but they are kinda biased as it seems there is no previous experience with both methods and are solely answering a question based on what MS has told you.
So far I'm just not sold on the .net way for this, I'm completely sold on allot of other new .net ways but this, please someone help me see the light. lol Just give me a solid example.
OK, first of all you aren't using a FileSystemObject. A FileSystemObject is a scripting object and you have to add a reference to the Windows Script library in order to access it. You're using standard VB6-style file I/O. The reason it still exists is for backward-compatibility.Quote:
Originally Posted by sytto
As the MSDN documentation states itself, My.Computer.FileSystem offers better performance than VB6-style I/O. There may well not be a direct equivalent to what you did there, but then there is no need for a direct equivalent. You wouldn't use FilePut to write the data in the first place so you wouldn't use FileGet to read it. In a .NET app you'd use a BinaryWriter/BinaryReader, binary or XML serialisation or a database.
Can you give me an example? That's all I'm looking for, as i said earlier it has eluded me.
What version of Visual Studio are you using?
Visual Studio 2005
Thank you all for replies.
Thank you Atheist for the MSDN article, that gave me info on fso limitations.