app.config and user.config files

[Mark]

..Net framework 2.0

I've read up on persisting user settings. As I understand it, the
app.config file contains both the application and user settings when
the app is first installed. A user then makes a change in the app that
is one of the user settings in app.config and I wish to persist this,
so I call the Save() method. This works fine.

However, I've noticed that only settings that have been written to are
"copied" to the user.config file when the Save() method is called.
Given that not all users have direct (file system) access to the
app.config file and are supposed to use their own user.config file, I
was surprised because I then wondered how they are supposed to even
know that some of the settings exist (those that they happened not to
change). Then I wondered if I'd misunderstood something fundamental
here: are users not supposed to be opening up their user.config files
in, say, notepad to see what settings exist? I'm now getting the
impression that it was never MS's intention that users would go into
their own config files directly, but I can't see any articles that
state that. (One hack is simply to assign all the settings to
themselves in code and then call Save(), which effecitvely "copies"
all the user settings in app.config to user.config. This works, but
I'm now wondering if I have a concept problem here!) Personally, I
can't see why we should tell users about their own user.config files.
After all, the whole point of the Settings class is to ensure that if
they enter gobbldygook into it, Settings will simply put things back
to default.

Any thoughts?

 

[Oliver Sturm]

Hello Mark,

Then I wondered if I'd misunderstood something fundamental
here: are users not supposed to be opening up their user.config files
in, say, notepad to see what settings exist?

I don't quite understand your question... I would never have assumed that
a user of an application I have written would go hunt around with notepad
in (for him/her) weirdly formatted text files. If I want to enable a user
to change an application setting, I offer some form of UI for him/her to
do that.

Maybe that doesn't make sense for your definition of "user"?


Oliver Sturm

 

[Mark]

Hello Mark,


I don't quite understand your question...

Looks like you've understood it perfectly.

I would never have assumed that
a user of an application I have written would go hunt around with notepad
in (for him/her) weirdly formatted text files.

Assumptions not necessary - my app loads the config file for them. As
for "weirdly formatted", well, let's take an example:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<userSettings>
<MyCo.MyApp.Properties.Settings>
<setting name="update_frequency" serializeAs="String">
<value>100</value>
</setting>
</MyCo.MyApp.Properties.Settings>
</userSettings>
</system.net>
</configuration>

Is it easier to say to a user "if you want to change the update
frequency from 100 to 200, change the value of 100 to 200 in this file
and save it. Or, is it easier to create a new form, test the new form,
document the new form, and put the form through change control every
time a new value is needed? For simple applications, I think (and
indeed know from experience) that the TCO for the former is less in
the long run. Bear in mind that MS have assisted this approach by
ensuring that if they mess up the file, it'll just revert to default
values anyway - so it's not like I'm asking them to edit the registry
or anything. It was this layer of protection provided by the Settings
class that made me think that MS had done things the way they had (and
the fact that users get their own individual config files) to make it
easier from a programmer's perspective to allow users to edit their
own config files.

However, if I understand you correctly, you think that users should
never be let near an XML formatted file? (Interestingly, the app I am
thinking of, which is used by about 400 people, has about 10 settings.
The level of user capability varies from people that can barely switch
on the computer to those with MCSEs. Now, the former category don't go
near the config file because it's scary! The latter do because they
know what they're doing. Either way, I don't recall a single support
issue from a badly edited config file.)

 

[Oliver Sturm]

Hello Mark,

However, if I understand you correctly, you think that users should
never be let near an XML formatted file?

Okay... I have this bad habit of reading from the top and commenting right
there - so I had written a few comments above that I have now removed.

You're right, that's what I'm saying - as long as you're not writing
developer tools. There are two reasons for it:

* My experiences with this kind of thing are different from yours, and based on that I don't estimate a shrinking TCO due to direct XML editing - rather the opposite.

* Maybe more importantly, it's not the quality standard I have when writing software. Very regularly there's a choice - one programmer can invest some time to implement a piece of functionality in a good way, or hundreds of users can spend additional time regularly to work with the bad implementation. Usually this calculation easily evaluates towards the good implementation and I'm sure it does in the case we're discussing. Actually I don't think I remember a case where that would not have been the case...


Oliver Sturm

 

[Peter Duniho]

[...]
Is it easier to say to a user "if you want to change the update
frequency from 100 to 200, change the value of 100 to 200 in this file
and save it. Or, is it easier to create a new form, test the new form,
document the new form, and put the form through change control every
time a new value is needed?

Easier for whom? Obviously, the former is easier for you, the programmer
(unless you also have to teach your users where to find the XML file and
how to edit it...not all users can simply be told to edit an XML file
where the location is given to them and have them understand what that
means). However, the point of writing software is to make things easier
for the user, not to make things easier for the programmer. And the
latter, while marginally more work for you, is easier for the user.

[...]
However, if I understand you correctly, you think that users should
never be let near an XML formatted file?

IMHO, it's not about *trusting* the user to edit the XML file. It's about
whether software should *make* the user edit the XML file. Frankly,
there's little you can do to prevent the user from mucking about in the
XML file if that's what they really want to do. The trust you may or may
not have in the user is irrelevant. The point is to not *force* the user
to do that.

And frankly, in .NET it is SO trivial to create a form with the various
options you are saving and connect the form's controls to the options in
the preferences file, I think it's a bit disingenuous to even raise the
question of how hard it is for you as the programmer.

(Interestingly, the app I am
thinking of, which is used by about 400 people, has about 10 settings.
The level of user capability varies from people that can barely switch
on the computer to those with MCSEs. Now, the former category don't go
near the config file because it's scary! The latter do because they
know what they're doing. Either way, I don't recall a single support
issue from a badly edited config file.)

Do the math. Assuming it only takes each user 60 seconds to find, edit,
and save the XML file to modify their settings, you've already wasted 400
minutes of their time. That's almost six person-hours, and that's just to
change the settings *once*. If you can't code up a form to let them
change the settings from within your program in six hours or less, you may
want to reconsider investing your time in programming.

Pete

 

[Mark]

Do the math. Assuming it only takes each user 60 seconds to find, edit,
and save the XML file to modify their settings, you've already wasted 400
minutes of their time. That's almost six person-hours, and that's just to
change the settings *once*. If you can't code up a form to let them
change the settings from within your program in six hours or less, you may
want to reconsider investing your time in programming.

Pete

Oliver: Interesting point - it started as a developer tool but, like
so many (MS tools in particular) grew into something more widely
available. I have a UI to the XML file on my change list, but as I
say, it's no one has ever asked for it (only about 5% ever need it as
the defaults nearly always work) and it hasn't generated a support
call, so it's always ended up being superseded by new functionality -
which does get requested regularly. I did wonder whether I should be
pushing for the XML UI as a priority over the new functionality but
the "key users" don't see the need. I suppose they could pay me to do
a TCO analysis to prove that it is required, but I'm sure they'll see
even less of a need for that!

Pete: I'm very sorry Pete, but I thought I was having a discussion
about something that was worth discussing with people that could think
"out of the box" things and had something useful to add to the
conversation. However, if your only recourse it to be insulting about
my programming ability (which this topic is certainly _not_ about),
then maybe one of us is wasting our time here and I'm more than happy
to accept that it is me.

 

[Peter Duniho]

Pete: I'm very sorry Pete, but I thought I was having a discussion
about something that was worth discussing with people that could think
"out of the box" things and had something useful to add to the
conversation.

I fail to see what is so "out of the box" about inconveniencing your users.

However, if your only recourse it to be insulting about
my programming ability (which this topic is certainly _not_ about),
then maybe one of us is wasting our time here and I'm more than happy
to accept that it is me.

So, you are asserting that both of the following are true:

* It will take you longer than six hours to implement a .NET form that
allows users to make changes to config file settings

* Programming is a worthwhile investment of your time

If either of those is false, then I fail to see what you have to be
offended about. I've only "insulted" your programming ability if you
actually can't implement the necessary UI in six hours. And it's not an
insult, it's a factual statement and was intended as such.

"Doth protest too much" comes to mind. You seem overly sensitive to
disagreement with your opinion that it's more important that you aren't
inconvenienced than that your users aren't. It seems likely to me that
you realize the fallacy in your argument and just aren't ready to accept
it yet.

Pete

 

[Mark]

So, you are asserting that both of the following are true:

* It will take you longer than six hours to implement a .NET form that
allows users to make changes to config file settings

* Programming is a worthwhile investment of your time

If either of those is false, then I fail to see what you have to be
offended about. I've only "insulted" your programming ability if you
actually can't implement the necessary UI in six hours. And it's not an
insult, it's a factual statement and was intended as such.

"Doth protest too much" comes to mind. You seem overly sensitive to
disagreement with your opinion that it's more important that you aren't
inconvenienced than that your users aren't. It seems likely to me that
you realize the fallacy in your argument and just aren't ready to accept
it yet.

Pete

Ah - a cowboy programmer, eh? One that measure the TCO of a project
purely in terms of it's inital dev time? You might find this useful
reading: http://en.wikipedia.org/wiki/Change_control. I did mention it
above, but I guess you either chose not to read it or were unable to
read it or unsable to understand it. (OK, I take it all back and take
my hat off to you if you're able to develop, write a test plan for,
test, modify as necessary, document, hand over to support and manage
change control all in 6 hours. I, sadly, cannot which I guess probably
does make me a rubbish programmer.) As for you failing to see where
you offend, we'll that's not really my problem.

 

[Peter Duniho]

Ah - a cowboy programmer, eh? One that measure the TCO of a project
purely in terms of it's inital dev time?

Quit putting words into my mouth.

Your assertion that providing a UI to allow the user to change settings is
ridiculous. We're not talking about some complicated feature here. We're
talking about user settings.

You have an entirely bogus argument for not doing the work. If your users
are happy with your lack of effort on their behalf, more power to you.
Suffice to say, the rest of us have more respect for those who use our
software.

 

[Oliver Sturm]

Was away for a week, so I don't want to write replies on each of your
posts... but:

You have an entirely bogus argument for not doing the work. If your users
are happy with your lack of effort on their behalf, more power to you. Suffice to say, the rest of us have more respect for those who use our software.

Mark, by and large I agree with Peter's statement, and I meant to say more
or less the same thing. FWIW.


Oliver Sturm