Fog Creek Software
Discussion Board

Welcome! and rules

Joel on Software

Store settings in object for easy save/loading?

I've always wanted to have a way to automatically save or restore all app settings (i.e., the stuff that used to be written to the .ini files).

I"m thinking that I could create a Serialized class, Settings, and then Save that as XML and then load it again at app startup.

Can anyone think of a better idea?

Mr. Analogy {ISV owner}
Tuesday, February 15, 2005

we do something similar for most of our in house apps.  i've always been a proponent of saving these in a db table (name - value pairs by user id).  several of my colleagues prefer to do this in xml files instead though - i think they have a generic class they use for this. 

Tuesday, February 15, 2005

To me, the critical thing is that the save/get is automatic for all settings.

I.e.,  If I create a new setting, I just add it to the Setting class and perhaps to the form where the settting is changeable by the user. But I do NOT have to add code, as I would previously, to the SaveMySettings() and GetMySettings() procedures of our programs.

The advantage of saving to XML is that there is an existing feature in .net to do this. You just (I think) pass it the class and it saves all the properties, etc.

Mr. Analogy {ISV owner}
Tuesday, February 15, 2005

I think the Settings class serialized as XML is a fine idea - because I've done it that way myself :)

If you're going to do it that way, put the settings into Isolated Storage so that users are guaranteed read/write access.

Mike Gunderloy
Tuesday, February 15, 2005

i just tried out the xml serialization - pretty cool.

Tuesday, February 15, 2005

I'll ditto the database recommendation -- typically we work on several (dozens) of applications within an organization and store the whole package (business data *and* configuration settings) in the centralized "enterprise database".

The only setting that's stored locally is how to connect to the database. From there, all settings are in the DB.

We basically have duplicated (and extended) the Microsoft architecture and API for the registry in a relational DB. It's a heirarchical setup like the regkeys/hives, and works on a heirarchical settings basis with GLOBAL_CONFIG, MACHINE_CONFIG, APPLICATION_CONFIG, PROCESS_CONFIG, USER_CONFIG.

You'll have to argue and decide the semantics -- e.g. do GLOBAL config options over ride USER config options (or vice versa) -- it can make sense either way, depending on your particula scenario(s).

Took about 3 weeks to develop and test, but has been used in dozens of applications successfully.

Sgt. Sausage
Tuesday, February 15, 2005

Ron Porter
Tuesday, February 15, 2005

*  Recent Topics

*  Fog Creek Home