By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
448,484 Members | 1,044 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 448,484 IT Pros & Developers. It's quick & easy.

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

P: n/a
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?
Nov 15 '05 #1
Share this Question
Share on Google+
7 Replies


P: n/a
In article <40**********************@news.skynet.be>,
Ol**********@skyscan.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.SpecialFolder enumeration). To re-load those
settings, just de-serialize the file.

--
Patrick Steele
Microsoft .NET MVP
http://weblogs.asp.net/psteele
Nov 15 '05 #2

P: n/a
> > 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.

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!!! :-)
Nov 15 '05 #3

P: n/a
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.

<Ol**********@skyscan.be> wrote in message
news:40*********************@news.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.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!!! :-)

Nov 15 '05 #4

P: n/a
> 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.
Nov 15 '05 #5

P: n/a
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**********@skyscan.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.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.

Nov 15 '05 #6

P: n/a
In article <40*********************@news.skynet.be>,
Ol**********@skyscan.be says...
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.


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
Nov 15 '05 #7

P: n/a
> > > 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.


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("LastU sed"; always returned
null,
I had to use
mLastUsedNode=mXmlDocument.SelectSingleNode("desce ndant::LastUsed") instead.
(see code sampple)

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

mLastUsedNode=mConfiguration.AppendChild(mXmlDocum ent.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_i n_between",
null, null, null);

I do like the XML file format!
I only hope that Micrsoft does something to make it more stabel.
Nov 15 '05 #8

This discussion thread is closed

Replies have been disabled for this discussion.