System.Configuration.AppSettin­gsReader

[mikeb]

Just wondering if I'm missing something completely here...

The AppSettingsReader only READS information from the app.config file. MS
provided no means of writing information to that file??

Use INIs
Don't use INI's, use registry
Don't use Registry, use .config

What in the world do I use to read to and write from configurations for my
app? I never did like to use the registry - loved ini files. Happy to use
..config files, but how do we write to it? Do I have to write my own wrapper
to do this??

 

[Marc Scheuner [MVP ADSI]]

The AppSettingsReader only READS information from the app.config file. MS

provided no means of writing information to that file??

Correct - the <myapp.exe.config> files are meant to be read-only by
design. Granted, on a single-user machine, that might sound silly, but
imagine using them in a corporate network environment - most normal
users will not even have write access rights to the directory where
they reside anyway!

For user-specific settings, use some other means - the easiest would
be to have a look at the "Configuration Management Application Block"
provided by MS, either stand-alone or as part of the MS Enterprise
Library. It allows storage of user-specific and machine-specific
settings into a great many "buckets" - XML-based config files in the
user's isolated storage area, or into a SQL Server, or anything else
you might dream of!

Marc

================================================================
Marc Scheuner May The Source Be With You!
Berne, Switzerland m.scheuner -at- inova.ch

 

[mikeb]

Its beyond silly, its rediculous.

If the app would be designed for a corp environment, only then one should
then have to worry about different handling methods of configuration. For
the rest of the apps out there, the majority, there is no reason why write
access to a config file wouldn't be advantageous.

In a corp environment, a sql table would be the choice. Most of our apps
are for the corp environment, but I doubt that is the way of all VS
developers. Even in a corp environment, write access to the config files
would work fine.

I still vote, a rediculous oversight.

 

[Marc Scheuner [MVP ADSI]]

Its beyond silly, its rediculous.
No, it's not.

If the app would be designed for a corp environment, only then one should
then have to worry about different handling methods of configuration. For
the rest of the apps out there, the majority, there is no reason why write
access to a config file wouldn't be advantageous.

Well, begs the question who the target audience for .NET and VS.NET is
- do you think MS targets mostly the stand-alone, hobbyist, small
business user? Or the large corporation with a corporate network and
tons of users connected?

It's always a question of design decisions - and those can be suitable
for your need, or not - but even if they're not exactly what you need,
that doesn't mean they're bad or silly. Maybe your requirements are
unusual, or silly !

Marc
================================================================
Marc Scheuner May The Source Be With You!
Berne, Switzerland m.scheuner -at- inova.ch

 

[Jonas Hei]

Check this:
http://www.interact-sw.co.uk/iangblog/2004/11/25/savingconfig

for dicussions about "Why Writing Into .NET Application Configuration
Files Is a Bad Idea"

You can also refer to:
http://msdn.microsoft.com/msdnmag/issues/05/04/AdvancedBasics/default.aspx
for more details.

 

[mikeb]

Yeah, ok Mark. MS doesn't make wrong decisions. You're right. Thats why
we've gone pretty much full circle. I remember someone telling me I was
washed up when I questioned the use of the registry over ini files too.
hmmm. I must be wrong again.

Hobbiests? I'll bet there are more smaller scale db apps than there are
corp apps. So yes, I do think its aimed less at what you consider corporate
apps. We write for all kinds of customers and systems, the majority are
smaller scale. How large of a team does it require to write large Visual
Studio solutions? Usually the same as it will for a smaller scale app
because the dev companies will accomodate those same sets at any time. MS
is not sold on usage, but on one off sales of VS. There are more hobbiest
(as you call them) than there are full scale dev houses. So again, yes, I
think they're targetting the smaller scale 'hobbiests' (whatever).

keep an eye out... I bet you my last nickle (remember go easy on me, I'm
only a "hobbiest") that a write method will be integrated soon.

 

[mikeb]

Jonas,
That explains the "why" well, and provides a solution.
Thanks for that.
Mike

 

[Marc Scheuner [MVP ADSI]]

MS doesn't make wrong decisions. You're right.

That's not what I'm saying - what I'm saying is that MS has to make
decisions, and they have to base them on their intended target
audience, and if you're doing something different, then those
decisions might not seem to make a lot of sense to YOU, but they might
be just fine for the actual target audience.

Just because something seems odd or wacky to YOU doesn't mean it's
brain-dead in the first place - maybe you're just not the "typical"
developer / scenario that MS had in mind when they made their design
decisions.

Design decisions are never right or wrong - they're always compromises
between a great number of factors.

As for your config settings - well, MS does provide the Configuration
Application Block (stand-alone or part of the MS Enterprise Library),
or you can find TONS of samples of how to create easy-to-use user
settings on e.g. http://www.codeproject.com.

And while you're at it, it might be a good idea from a business
standpoint to think about how to can create your apps in such a way
that - heaven should forbid! - a corporate customer is ever interested
in your app, you wouldn't have to go rewrite half your app because you
wrote it in such a way that it wouldn't work on a corporate
network.... that's all I'm saying - why not create your app in such a
way that it *would* run just fine in a network environment? Why insist
on doing it in a way that will DEFINITELY break it in such an
environment? Just plain doesn't make sense to me.

Marc
================================================================
Marc Scheuner May The Source Be With You!
Berne, Switzerland m.scheuner -at- inova.ch