Retaining Application and/or User Settings with ClickOnce Upgrades

Hi,

This is regarding using ClickOnce to manage installation and retaining settings. (This will be my first time using ClickOnce.)

I could also deploy without using ClickOnce, if that resolves the problem.

Background:
The project is test SW deployed to manufacturing sites on PCs owned by my company of which I am admin. The test SW will run identical processes on all stations at all sites. The operators will not alter any settings, application or user; they must be as I need them set. These settings will very rarely be changed.

There are basically three types of settings,
1. Common to all stations at all locations (e.g., expected HW version)
2. Common to all stations and unique to each location (e.g., site location identifier)
3. Unique to each station and unique to each location (e.g., IP address setting)

Here is a simple graphic of the deployment:
........Site X......................Site Y
...........|...........................|
..|--------|--------|.........|--------|--------|
Sta A .. Sta B .. Sta C ... Sta D .. Sta E .. Sta F
-User1 . -User1 . -User1 .. -User4 . -User4 . -User4
-User2 . -User2 . -User2 .. -User5 . -User5 . -User5
-User3 . -User3 . -User3 .. -User6 . -User6 . -User6

These are what I would like to figure out:

1. How to retain the settings on each station for each user when updating the SW.

2. The settings will be the same for all users on a given station. I won’t know the passwords of users (though I could get them using VB). User’s will be added and removed over time. Should all settings be Application settings to avoid having to manage each user’s User config file on each station?

3. Is a persistent “master” config file that updates or overwrites the app config file a good idea? How best to manage the master and Application files when settings are added or removed on a new deployment?

4. I would appreciate any other advice regarding this.

The settings that are common and are not going to change should be application settings. Those are read-only by design. Anything else should be a user setting.
That said, this is how config settings work. When an application starts up, there's several config files that get read in and overlaid on top of each other, with each one overriding (where there's overlap) settings previously set.
First there's "machine.config" ... I forget where this is stored, but this is used to set config values that will be common to all .NET applications on the machine. We used this in a previous life of mine to control db connections, so that all apps were using the same connection settings. It's also where we set environmental values for production. Next comes the application.config file. This file contains the configurations for all the application vlaues for that applicaiton, as well as the defaul.t values for any user settings. Last to be loaded and applied is the user settings file for that application. Any application setting that the user has overriden, or changed, is stored here.

So: 1) Use User-scopped settings where it makes sense. For things that the user can change and configure, this is what they are for. It will get stored per user, so it won't get overwritten.
2) For settings that won't change, make them Applicaiton-Scoped settings. No need for passwords or anything related to the user.
3) No. Just use the settings and scoped to either Application or User. If you add a new value, it gets added to the applicaiton.config file, and will deploy on the next install.

-tg