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

[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?

 

[Patrick Steele [MVP]]

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?

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.

 

[Guest]

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.

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!!!

 

[Guest]

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.

 

[Guest]

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.

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.

 

[Guest]

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.

 

[Patrick Steele [MVP]]

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.

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.

 

[Guest]

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.

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.