Is XML Config files for project specific settings the best approach...

Hi all,

I have the scenario where I have a Class (assembly) that applies settings that are specific for each proejct that we rollout. Now, the question I ask is, where is the bet place to store these specific settings For example, we will be rolling out to mobile devices, where each device has its own set of features, so we need to cater for them, as well as project/cleint specific features. Is it best to store these details in a XML config file (is it app.config) for each project and then draw out these settings and pass them through to the class/assembly that will then apply these settings

For example, we have a client who needs their device volume set to maximum when the application is run, so I would have an element in the app.configt file for that project to say that they volume needs to be set to max, and then this is passed and handled to the class/assembly to handle this

Am i think down the right route here

Thanks

Tryst

Answer this question

Is XML Config files for project specific settings the best approach...

Jazza68
You have the following options as far as configuring your app (in my opinion):

1) Compile-time constants
2) Configuration file -> per application/machine or per user
3) Registry

Compile-time constants should be used when you are worried about performance or the values can not change without recompiling the code. This option is good for things like application paths or other values that make no sense being configurable.

Configuration files (either kind) should be used when the application settings can be changed by the user or an administrator to meet their needs and won't require a recompilation. For example addresses to servers, credential information, website titles, etc. are good for storing in configuration files as they can be changed without impacting the code. Configuration files are cached so performance is really good.

The registry is also a good place to store things but it removes the ability to xcopy code (not normally a problem) and is harder to change for a user. Security gets in the way here. This is a good thing however as settings that must be secured should be stored in the registry along with proper ACL settings. For example passwords and their settings are often stored in the registry such that only privileged people can see and/or change the values.

In your case a combination of compile-time constants (perhaps application names, company names, etc) are good while most other settings should be stored in a config file. My rule of thumb is "Can the end user change the values and it matter" If yes then use a config file. If no consider using a compile-time constant.

Michael Taylor - 6/12/06
Huw Parker

Hi Tryst,

I agree with Michael's suggestion.
Because this newsgroup is mainly for desktop application development, I am not sure if it has any speical usage of ini in an embedded environment.

In the Desktop development the ini file is gradually replaced by xml config file.

As Michael said, the app.config file is per appdomain, so common one exe will have only one app.config, if you have special requirement, you can use another xml file as the config file, and the .NET provide XML support to handle XML file easierly.

If you still have any concern, please feel free to post here.

Best regards,
Peter Huang
Nemorarius
It depends. If everything is pre-determined. I would use xml or something similar. If the client is supposed to make choices, I would (also) use a setup procedure or options page in combination with a .ini file.

Regards,

Guido
Mark Wheeldon
hi. and thanks for the replies.

But isn't an app.config file meant to supercede the .ini file

Tryst
Is XML Config files for project specific settings the best approach...

Answer this question