Best way to Read/write user/machine setting configuration files

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

In the beginning we had Ini files.
Later we had registery files.
Now have xml files and our read-only myapp.config file.

My question now, is what is the best way to store and load user and machine
specific settings for a .NET program?
And what classes, or code do we have to do this in C#?

I don't think that using the myapp.config is the best choice to store since
the file might be read-only if the program is started from a CD ROM, or if
the user does not have enough rights in the "program files" folder. So the
"My documents" choice might be better, or the registery? But this might be
read-only too?
 
In the beginning we had Ini files.
Later we had registery files.
Now have xml files and our read-only myapp.config file.

My question now, is what is the best way to store and load user and machine
specific settings for a .NET program?
And what classes, or code do we have to do this in C#?

I don't think that using the myapp.config is the best choice to store since
the file might be read-only if the program is started from a CD ROM, or if
the user does not have enough rights in the "program files" folder. So the
"My documents" choice might be better, or the registery? But this might be
read-only too?
Click to expand...

You could serialize a simple class to the users' application directory
(see the Environment.SpecialFolder enumeration). To re-load those
settings, just de-serialize the file.
 
In the beginning we had Ini files.
You could serialize a simple class to the users' application directory
(see the Environment.SpecialFolder enumeration). To re-load those
settings, just de-serialize the file.
Click to expand...
Well, this helps part of my problem.

The second problem is this serialization, because I want Myprogram v1.0
still be able to read Myprogram v1.5 settings and vice versa.
A lot of sollutions I found are not worth it since it somehow converts the
v1.0 to v1.5 and no way to return back. So I am stil looking into this to
find a elegant sollution.

But thanks for the tip!!! :-)
 
If serialization isnt the best way for you then how about just make your own
XML format and use XmlDocument.Load(string filename) and
XmlDocument.SelectSingleNode(xPath);

I do this for my config files, I use "Root.Node.Node.Key" to get that
functionlity of an ini file.

I can also encrypt this by storing as base 64 strings to a file and Loading,
decrypting and XmlDocument.LoadXml(unencryptedXmlstring);

Works best for me when a custom format is required and serialization isnt
working well.
 
If serialization isnt the best way for you then how about just make your
own
XML format and use XmlDocument.Load(string filename) and
XmlDocument.SelectSingleNode(xPath);

I do this for my config files, I use "Root.Node.Node.Key" to get that
functionlity of an ini file.

I can also encrypt this by storing as base 64 strings to a file and Loading,
decrypting and XmlDocument.LoadXml(unencryptedXmlstring);

Works best for me when a custom format is required and serialization isnt
working well.
Click to expand...
This was the idea I was looking into, originally I used ini files and
registery, but I might use xml now, since it has a lot of potential.
 
You can easily edit them with XMLNotepad (which you cant do if its
serialized it just complains), XMLNotepad is no longer supported though but
it works.
 
Well, this helps part of my problem.

The second problem is this serialization, because I want Myprogram v1.0
still be able to read Myprogram v1.5 settings and vice versa.
A lot of sollutions I found are not worth it since it somehow converts the
v1.0 to v1.5 and no way to return back. So I am stil looking into this to
find a elegant sollution.
Click to expand...

You could implement the ISerializable interface and control
serialization/deserialization yourself. During serialization, you could
write out a version number. Likewise, during deserialization, you could
read this version number and make sure your current application supports
that version.
 
You could serialize a simple class to the users' application directory
You could implement the ISerializable interface and control
serialization/deserialization yourself. During serialization, you could
write out a version number. Likewise, during deserialization, you could
read this version number and make sure your current application supports
that version.
Click to expand...

For the moment I am using the xml direction (XmlDocument).
At first I thought this was something like ini files, just a little bit more
nestend then it turns out that it is far advanced, it is close to a
database.

I had some small problem with reloading the file an add things to it without
losing the other unknown information.
I wanted a program v1.0 to read a v2.0 xml configuration file, and save the
settings whie it stays a v2.0 xml file, thus the v2.0 program still have all
it's configuration available. Only when I see that some nodes are missing, I
add them.

It took me some time to realize that mXmlDocument.SelectSingleNode() has
some SQL-like (actually XPath) syntax.
So mLastUsedNode=mXmlDocument.SelectSingleNode("LastUsed"; always returned
null,
I had to use
mLastUsedNode=mXmlDocument.SelectSingleNode("descendant::LastUsed") instead.
(see code sampple)

--------------------------
mLastUsedNode=mXmlDocument.SelectSingleNode("descendant::LastUsed");
if (mLastUsedNode==null ) {

mLastUsedNode=mConfiguration.AppendChild(mXmlDocument.CreateElement("LastUse
d"));
}
----------------------

One other thing that I now realize is to filter the characters that you re
going to save. Filling in a string "<blabla" might crash the xml.
The same typical problems SQL databases have.

The xml direction is a good direction what I want to do.
Only the stability scares me a little, it is as unstable as other database
engines.
e.g. I open the xml file with notepad, an it crashes my explorer.
Other example is something like this:
mDoctype = mXmlDocument.CreateDocumentType("this has spaces in between",
null, null, null);
It also crashes my explorer. :-(

But this fixes it
mDoctype = mXmlDocument.CreateDocumentType("this_has_spaces_in_between",
null, null, null);

I do like the XML file format!
I only hope that Micrsoft does something to make it more stabel.
 
Back
Top