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

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 article <40************ **********@news .skynet.be>,
Ol**********@sk yscan.be says...

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.Spe cialFolder enumeration). To re-load those
settings, just de-serialize the file.

--
Patrick Steele
Microsoft .NET MVP
http://weblogs.asp.net/psteele

> > 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.Spe cialFolder 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!!! :-)

If serialization isnt the best way for you then how about just make your own
XML format and use XmlDocument.Loa d(string filename) and
XmlDocument.Sel ectSingleNode(x Path);

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.Loa dXml(unencrypte dXmlstring);

Works best for me when a custom format is required and serialization isnt
working well.

<Ol**********@s kyscan.be> wrote in message
news:40******** *************@n ews.skynet.be.. .

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.Spe cialFolder 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!!! :-)

> If serialization isnt the best way for you then how about just make your
own

XML format and use XmlDocument.Loa d(string filename) and
XmlDocument.Sel ectSingleNode(x Path);

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.Loa dXml(unencrypte dXmlstring);

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.

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.

<Ol**********@s kyscan.be> wrote in message
news:40******** **************@ news.skynet.be. ..

If serialization isnt the best way for you then how about just make your

own

XML format and use XmlDocument.Loa d(string filename) and
XmlDocument.Sel ectSingleNode(x Path);

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.Loa dXml(unencrypte dXmlstring);

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.

[Patrick Steele [MVP]]

In article <40************ *********@news. skynet.be>,
Ol**********@sk yscan.be says...

You could serialize a simple class to the users' application directory
(see the Environment.Spe cialFolder 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.

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.

--
Patrick Steele
Microsoft .NET MVP
http://weblogs.asp.net/psteele

> > > You could serialize a simple class to the users' application directory

(see the Environment.Spe cialFolder 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.

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.Se lectSingleNode( ) has
some SQL-like (actually XPath) syntax.
So mLastUsedNode=m XmlDocument.Sel ectSingleNode(" LastUsed"; always returned
null,
I had to use
mLastUsedNode=m XmlDocument.Sel ectSingleNode(" descendant::Las tUsed") instead.
(see code sampple)

--------------------------
mLastUsedNode=m XmlDocument.Sel ectSingleNode(" descendant::Las tUsed");
if (mLastUsedNode= =null ) {

mLastUsedNode=m Configuration.A ppendChild(mXml Document.Create Element("LastUs e
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.Cr eateDocumentTyp e("this has spaces in between",
null, null, null);
It also crashes my explorer. :-(

But this fixes it
mDoctype = mXmlDocument.Cr eateDocumentTyp e("this_has_spa ces_in_between" ,
null, null, null);

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