Application settings lost upon new assembly  
Author Message
Jef Patat





PostPosted: Visual C# General, Application settings lost upon new assembly Top

Hi all,

I'm facing the same problem as issued in this topic.

I tried the solution with ApplicationSettingsBase.Upgrade() but it doesn't work out. First of all I need to put System.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.



Visual C#20  
 
 
Dan Dittenhafer





PostPosted: Visual C# General, Application settings lost upon new assembly Top

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


 
 
Jef Patat





PostPosted: Visual C# General, Application settings lost upon new assembly Top

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


 
 
Jef Patat





PostPosted: Visual C# General, Application settings lost upon new assembly Top

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!


 
 
Muhammad Arif





PostPosted: Visual C# General, Application settings lost upon new assembly Top

First create an object of ApplicationSettingsBase then you will get the actual intellisense for this class.

 
 
Dan Dittenhafer





PostPosted: Visual C# General, Application settings lost upon new assembly Top

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


 
 
Mark Benningfield





PostPosted: Visual C# General, Application settings lost upon new assembly Top

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.



 
 
Dan Dittenhafer





PostPosted: Visual C# General, Application settings lost upon new assembly Top

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


 
 
Mark Benningfield





PostPosted: Visual C# General, Application settings lost upon new assembly Top

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.



 
 
Dan Dittenhafer





PostPosted: Visual C# General, Application settings lost upon new assembly Top

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


 
 
Mark Benningfield





PostPosted: Visual C# General, Application settings lost upon new assembly Top

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.