Application settings lost upon new assembly
Hi all,
I'm facing the same problem as issued inthis topic.
I tried the solution with ApplicationSettingsBase.Upgrade() but it doesn't work out. First of all I need to putSystem.Configuration in front of it, I don't know if this really matters. Second my intellisense only offers me .Equals, .ReferenceEquals and .Synchronized but no Upgrade.
My application is working correctly, I assigned settings using the Settings designer and I use them using Properties.Settings.Default. ...
To be honnest I've been reading a bit here and there but I miss the total picture, I do not see where I mess up.
All help is appreciated.
[1207 byte] By [
JefPatat] at [2007-12-27]
Jef,
First, I suggest adding the System.Configuration namespace to your imports section as the top of your code file:
using System.Configuration;
The Properties.Settings class is meant to be instantiated as in:
Properties.Settings mySettings = new Properties.Settings();
This will give a user specific instance of the settings which you can update and save:
mySettings.ASetting = oSettingValue;
mySettings.Save();
Additionally, the mySettings object will now yield methods including Upgrade() in your intellisense.
Dan
Thanks a lot for the response Dan!
I still have to try it but it looks promissing. Why instantiate it this way? I was using it like:
Properties.Settings.Default.ASetting
and I could also use
Properties.Settings.Default.Upgrade();
but that did not work, how comes? I will try and come back to comment if it works or not.
Kind regards, Jef
Hi again,
just to mention it works out perfectly. I still do not see the difference, if anyone can explain it that would be helpfull.
Thanks a lot!
First create an object of
ApplicationSettingsBase then you will get the actual intellisense for this class.Hi Jef,
The Properties.Settings.Default object is a static instance that is designed to represent the original default settings a new installation or new user would receive. By instantiating your Properties.Settings class, you get a user specific instance of settings that you can change and save for that user. When saved, the user specific settings are then persisted automatically to the Documents and Settings\userid\Local Settings\Application Data\AppName_versiontoken\user.config file. If you call Upgrade on the instantiated Settings object, you invoke a migration of the user's version of the settings to the next version of you application.
Glad to help!
Dan
Hello All.
Jef Patat and Dan:
First of all, Jef Patat, when you say that Properties.Settings.Default.Upgrade() is not available to you on Intellisense, then you haven't got something quite right, because it's supposed to be there, and it usually is. You might double-check that your Settings.settings file is located under the Properties folder in Solution Explorer, and that it's Custom Tool property is set to SettingsSingleFileGenerator.
Dan, the behavior you speak of is directly available on the Properties.Settings.Default object. For example:
Properties.Settings.Default.Setting1 = 5;
Properties.Settings.Default.Save();
This results in the changed settings being saved in the current user's isolated storage, in the path you described. You shouldn't have to instantiate a new Properties.Settings object.
Granted, the work-around you folks have come up with will work, but it shouldn't be necessary. Something isn't quite smurfy.
HTH.
Hi Mark,
I wouldn't call the techinique we've been discussing a workaround. It is plainly documented as an option for accessing a settings object in this article (along with your technique as well):
http://msdn2.microsoft.com/en-gb/library/z76x4k8b(vs.80).aspx
If you created your settings by deriving from ApplicationSettingsBase directly, you need to instantiate your class manually.
MyCustomSettings settings = new MyCustomSettings();
I am glad to learn that the Default object provides this behavior as well. I hadn't considered that before.
Thanks!
Dan
Hello All.
Dan:
No, I agree that if the ApplicationSettingsBase approach is used, then instantiation is required. Certainly. My point (belabored as it is) is that deriving from ApplicationSettingsBase shouldn't be necessary, in most cases. If you don't require the finer degree of control over the settings objects that that provides, but simply want to configure, read, and save settings on a per-user basis, then Properties.Settings.Default is all you need to do.
The larger point that I tried to make is that if Properties.Settings.Default isn't working, then something is out of kilter somewhere, because it generally does. It shoudn't be necessary to derive from ApplicationSettingsBase just to get your settings machinery to work properly. Do you see what I mean?
HTH.
Hi Mark et al,
Ah yes, I see what you are saying... if someone is using the VS2005 Settings Designer to manage their settings, then the Properties.Settings.Default should be the only instance they would need to access, as it doubles for the defaults if no user-specific settings exist, and will automatically handle user-specific settings if they are found in the user's application data area. It's too bad there isn't much documentation to be found on this topic. I did finally find this article that specifically reenforces this understanding of the Properties.Settings.Default:
http://msdn2.microsoft.com/en-us/aa730869(vs.80).aspx
I now fully concur with your take on our discussion: that if the Properties.Settings.Default isn't providing this expected functionality, then something "isn't quite smurfy".
Thanks for the clarification!
Dan
Hello All.
Dan:
Yes, unfortunately, the docs on this subject are much more convoluted than they ought to be. It seems as though the documentation didn't keep up with the progress of the implementation. I can tell that MS makes a large effort to keep the docs accurate, but it seems that "well-organized" occasionally takes a back seat. 
