Question How do Application Settings really work?

[UncleRonin]

I've used application settings (My.Settings) in previous projects before and they worked out just fine. I use them now in my current project though and it's a total mess!

Previously I had my applications using the Exe.config file from within the application folder. I did nothing other than set up those application settings in the VS IDE and run my apps. When i wanted to change a setting I would do so manually and edit the Exe.config directly. Everything worked 100%.

This time, however, if i make a change to the Exe.config it is totally ignored and instead any changes have to be made to User.config in the user folder.

If I copy my application to a new PC with just the local Exe.config and I specify the settings there before running it, why aren't these settings used by the application? Instead the defaults are always used and no user.config even exists until My.Settings.Save is called. If I delete the local Exe.config then the application throws an error because it can't load the config! What's going on here? If there is no actual point in using the local Exe.config then why does it complain about it being missing?

Ideally what I want to do is use the local Exe.config ONLY. Access to it is not restricted and it simplifies the basic configuration process since all the database locations and communication settings are specified there. If I can't change the settings in the local Exe.config what is point of it's existence??

I know there are a whole bunch of .configs scattered all over the place and there is a precedence to them but there must be a way of saying 'Listen here, you lot back off' and then only the one very specific, very accessible and very logical .config is used. The same settings are used by all users but they are modifiable.

To me the defaults are there for the first use only and the local configs are the ones that should be used.

This is seriously driving me insane!

I've reached the point where I'm going to scrap the application settings and just use a basic XML file that does the same thing because things are just not working out...

Help me #(

 

[cjard]

If the application setting is Application Scope the value is always gotten from the applicationname.exe.config file
If the application setting is User Scope, the value is gotten from the config file found in the user section that relates to the version of the file that is installed unless that file does not exist in which case it comes as per above

When you install a new version, it stores user settings at a new path thus old settings are no longer used.

The first time an app is installed, as far as I'm aware, there is no user config file made by the installer, so the defaults found in the application.exe.config file are used as defaults for all the user scoped settings and the user sets are created (in the versioned path) the first time prefs.save is used.


Do not use User Settings to store prefs that a user should not change, such as db query texts, possibly connections strings etc


DLLs never have config files; the prefs are built into the DLL and cannot be changed
Services have application configs but not user configs (i think)

 

[JohnH]

I'm not sure from your description exactly where and how you apply settings in the deployment scenario, read through this article and see how it may apply to you Using My.Settings in Visual Basic 2005

 

[cjard]

If I can't change the settings in the local Exe.config what is point of it's existence??

applicationname.exe.config is where the developers put important things that users should not meddle with
prefs that the users may edit should be, for example, the background colour or picture on the form, which db they were last linked to, where their default save location is, what printer they have configured; stuff that is personal and doesnt make sense to share to everyone

very specific, very accessible and very logical .config is used.

Horses for courses. I wouldnt want my form background to be bright pink just because the girl that does the shredding thinks it's cute, and similarly, giving her ability to change the db connection string would be Bad

The same settings are used by all users but they are modifiable.

So any one of them can screw them up? The App Scope settings are not runtime writable because they are things that should be set by a developer who knows what he is doing and then not modified by users.

To me the defaults are there for the first use only and the local configs are the ones that should be used.

App Scope are not "defaults that the users can customise into their personal configs".. Put your 10 connection strings in App Scope, then make the "name of which one the user wants to use" a User Scope.. Users cannot connect arbitrarily to databases, nor can one user define a new db for the entire comapny. The developer does that

Hope this helps

 

[UncleRonin]

Shot for the responses!

It's an application running in an industrial environment (they almost always are these days :\) and the people using it are NOT computer literate. Besides the main application they will not access any of the application files and if they do my company reserves the right to make them pay for any time we spend fixing their mistakes - so no one is gonna fiddle. In general they will not even use the PC unless there is a fault somewhere and everything will remain automated.

That being said most of the configuration options can be specified through the use of the application (restricted users) but should also be accessible by directly modifying the file (the users don't even realise there IS a file and only people from my company do). It's faster to make a simple change from COM1 to COM4 in the file than through the application because of logging in, etc. For maintenance purposes it helps being able to specify options in the file directly seeing as though the period of time we have available for maintenance is max 30 minutes at a time.

The configurable options are things like com ports and printers and there is only one application config so that it will behave the same regardless of the user that is currently logged in.

For testing certain things during development and on site, being able to modify the configuration file makes a HUGE difference otherwise it slows down the testing considerably.

I had one problem where the database server location was a user setting and the default is set to the local PC but when running on a PC without a server it kinda made it IMPOSSIBLE to run the application. Eventually I had to copy user.config from my own PC (full directory structure) and copy that to this other PC in order for it to work because none of the settings in the exe.config were updated even if the file was changed and there were no other settings. Changing the con strings to app settings should solve this though.

I've checked my other projects and they were all using user settings stored in exe.config and they worked perfectly fine when modified directly so I find this all kinda confusing.

Technically these settings will never really change in the first place but I don't understand why modifying exe.config does not update the settings globally?

 

[JohnH]

So what you are saying is that you are going out to the deployed computer and manually change a user setting in exe.config. From how I understand My.Settings that is not supposed to work, as user settings is only created "first time" from the deployed exe.config, and only a runtime My.Settings.Reset will reset to defaults.

Since the My.Settings files is designed to not be messed with manually I would consider other options.

 

[UncleRonin]

That's a pity because it is super convenient and easy to use. It would be nice if there was a way of specifying in the exe.config the order of precedence for the configs and whether or not user specific configs are to be used, etc.

But ja. Thanks again for all the help! Learned quite a bit and that's always a good thing

 

[cjard]

Technically these settings will never really change in the first place but I don't understand why modifying exe.config does not update the settings globally?

If you've set the Settings to be User Scope, and knowing that User Scope settings are read from and written to the version dependent user config file in the user's profile NOT the applicationnam.exe.config in the same dir as the application...
...Why would you expect that modifying applicationname.exe.config would have any bearing on the settings?

That would be like me having a copy of my resumee on my work pc and my home pc, editing the home copy and wondering why the work copy didnt show any changes


I suggest that you make all your settings into Application Scope ones, and if you have to change the prefs, use remote file sharing or something to edit the file. Next time the user starts the app the sets will change to your edits. This also avoids the need to:
a) visit the machine
b) interrupt the user

Stuff like COM ports should be autodetected, reduces the risk of problems biting you

 

[cjard]

That's a pity because it is super convenient and easy to use. It would be nice if there was a way of specifying in the exe.config the order of precedence for the configs and whether or not user specific configs are to be used, etc.

There is that order: If setting is User Scope and no user file exists, use the defaults from the application file.

All your description so far indicates that you want Application Scope functionality; what ARE you messing around with User Scope for?

 

[UncleRonin]

I have a bunch of settings like DB related stuff that are application settings and won't change unless the exe.config is edited. I also have a bunch of modifiable settings that can be changed from within the application. These modifiable settings are application settings but users can change them like com ports and baud rates.

How do you propose I handle that?

I suggest that you make all your settings into Application Scope ones, and if you have to change the prefs, use remote file sharing or something to edit the file. Next time the user starts the app the sets will change to your edits. This also avoids the need to:
a) visit the machine
b) interrupt the user

Stuff like COM ports should be autodetected, reduces the risk of problems biting you

Making them all application settings would be easier but then I can't modify them programmatically from My.Settings surely?

There are at least 5 com ports on the PC so auto detection isn't an option. As far as making the selection of com ports easier I enumerate it using the typical ports list from .NET.