C# usersettings opnieuw invullen na nieuwe release

[pkouwer]

Geachte,

ik heb een (tijdleijke) applicatie ontwikkeld in C# welke gebruikt maakt van een aantal usersettings. Ik ben me er van bewust dat dit niet de beste methode is, maar dat even ter zijde.

telkens als er een nieuwe release komt (in dit geval in een testomgeving), moet ik deze user setting opnieuw invullen. Is hiervoor een andere manier of oplossing, want als ik dit zo ga gebruiken en er komt een nieuwe release, dan wordt je niet echt vrolijk.

[harrald]

die usersettings sla je dan ergens op denk ik?
bij de nieuwe release kan je dan toch gebruik maken van die gegevens?

misschien dat je je situatie iets meer moet uitleggen want momenteel zie ik geen probleem.

[CodeCaster]

Op welke wijzen kun je in C# verder nog gegevens wegschrijven en weer uitlezen? Ik denk dat je vast zit aan een bestand of het register.

[Reptile209]

Ik zou idd een bestandje in het userprofile zetten, of in het register. Hou in je app wel rekeningn met settings die na een upgrade (of het overslaan daarvan) niet meer kloppen of relevant zijn.

[pkouwer]

het gaat hier om de standaard methode om de US uit te lezen en weg te schrijven.

[urk_forever]

C#:

Properties.Settings.Default.Upgrade()

is waarschijnlijk wat je zoekt.

[pedorus]

quote: http://blogs.msdn.com/rprabhu/articles/433979.aspx

Q: Why is there a version number in the user.config path? If I deploy a new version of my application, won't the user lose all the settings saved by the previous version?

A: There are couple of reasons why the user.config path is version sensitive. (1) To support side-by-side deployment of different versions of an application (you can do this with Clickonce, for example). It is possible for different version of the application to have different settings saved out. (2) When you upgrade an application, the settings class may have been altered and may not be compatible with what's saved out, which can lead to problems.

However, we have made it easy to upgrade settings from a previous version of the application to the latest. Simply call ApplicationSettingsBase.Upgrade() and it will retrieve settings from the previous version that match the current version of the class and store them out in the current version's user.config file. You also have the option of overriding this behavior either in your settings class or in your provider implementation.

Q: Okay, but how do I know when to call Upgrade?

A: Good question. In Clickonce, when you install a new version of your application, ApplicationSettingsBase will detect it and automatically upgrade settings for you at the point settings are loaded. In non-Clickonce cases, there is no automatic upgrade - you have to call Upgrade yourself. Here is one idea for determining when to call Upgrade:

Have a boolean setting called CallUpgrade and give it a default value of true. When your app starts up, you can do something like:

C#:

   if (Properties.Settings.Value.CallUpgrade) {
      Properties.Settings.Value.Upgrade();
      Properties.Settings.Value.CallUpgrade = false;
   }

This will ensure that Upgrade() is called only the first time the application runs after a new version is deployed.

[pkouwer]

dit lijkt te werken, ik zal het morgen testen,

thnx !!

[Spiral]

Maak gebruik van isolatestorage deze is bedoeld voor gebruikersinstellingen. Het werkt op gebruikersniveau en computerniveau.

Vanaf Windows NT4

http://msdn.microsoft.com/en-us/library/3ak841sy(VS.80).aspx

[pedorus]

Ehm, daar staat het nu al...

quote: http://blogs.msdn.com/rprabhu/articles/433979.aspx

Q: You said user.config files go in the user data path. How can I locate the file? Are there multiple files for an application or just one?

A: As mentioned before, the default SettingsProvider for client applications (called the LocalFileSettingsProvider) stores settings in the application configuration files. In .NET v1 and v1.1, there were two levels of config files - machine.config and app.exe.config (where 'app.exe' is the name of the application). In v2.0, we have added two more levels of configuration to store user specific data - one that goes in the roaming user profile path and another in the local user profile path. On XP, the profile directories would be something like 'c:\Documents and Settings\<username>\Application Data' and 'c:\Documents and Settings\<username>\Local Settings\Application Data' respectively. These directories are the recommended location (per Windows Logo requirements) for storing user specific information and most applications (like Outlook and Visual Studio) put user data somewhere under here.

The exact path of the user.config files looks something like this:

<Profile Directory>\<Company Name>\<App Name>_<Evidence Type>_<Evidence Hash>\<Version>\user.config

where

<Profile Directory> - is either the roaming profile directory or the local one. Settings are stored by default in the local user.config file. To store a setting in the roaming user.config file, you need to mark the setting with the SettingsManageabilityAttribute with SettingsManageability set to Roaming.

<Company Name> - is typically the string specified by the AssemblyCompanyAttribute (with the caveat that the string is escaped and truncated as necessary, and if not specified on the assembly, we have a fallback procedure).

<App Name> - is typically the string specified by the AssemblyProductAttribute (same caveats as for company name).

<Evidence Type> and <Evidence Hash> - information derived from the app domain evidence to provide proper app domain and assembly isolation.

<Version> - typically the version specified in the AssemblyVersionAttribute. This is required to isolate different versions of the app deployed side by side.

The file name is always simply 'user.config'.

If you want to get to the path programmatically, you can do it using the Configuration Management API (you need to add a reference to System.Configuration.dll). For example, here is how you can get the local user.config file path:

C#:

   Configuration config = ConfigurationManager.OpenExeConfiguration(ConfigurationUserLevel.PerUserRoamingAndLocal);
   Console.WriteLine("Local user config path: {0}", config.FilePath);

[Spiral]

pedorus schreef op dinsdag 15 december 2009 @ 10:16:
Ehm, daar staat het nu al...
[...]

Bedoel je daarmee de locatie van de bestanden? Want mij ging het juist om het gemak waarmee je m.b.v. de IsolatedStorage klasse dit soort applicatiedata kunt opslaan. De plek is voor mij oninteressant geworden omdat de API dat het beste weet. (naja in de meeste gevallen)