 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
.NET Forum / .NET Framework / New Users / January 2008User Settings
I added some user settings to my app which caused the Settings.settings to be generated etc... and all was well and lovely and the Sun was shining. Then I changed the version number of my assembly (it had been updated, after all) and all of my settings disappeared, which was somewhat less than lovely and the clouds came rolling in. I gather the user.config file that the Properties.Settings class saves is assembly version specific. Is there any way to override that so I can retain the settings across all versions of my app? Thanks Steve Is it that no one uses the generated Settings class and user.config file? Perhaps I'm wasting my time with this feature? Anyone have an opinion? Steve >I added some user settings to my app which caused the Settings.settings to >be generated etc... and all was well and lovely and the Sun was shining. [quoted text clipped - 9 lines] > Thanks > Steve > Is it that no one uses the generated Settings class and user.config file? > > Perhaps I'm wasting my time with this feature? > > Anyone have an opinion? I use it all the time. But I don't have the requirement to preserve the settings across updates of my programs, so I've never actually had to solve the problem you're asking about. I can't speak for everyone else, but just because you haven't received a response to your question, that doesn't mean no one's using the feature. At best, it means no one's trying to use it the way you want to use it. That said, I suspect there _is_ a solution to your problem. I think the Settings class would be much less useful if users had to start from scratch every time the program was updated. I just don't happen to know what that solution is. Sorry... Pete Hi Steve, I use User Setting quite often, but have never tried to deal with the issue of persisting settings across versions of the application. I suspect that the best way to do this would be to use the System Registry for such settings, as it is in a well-known location that will not change, and will persist the settings as long as either your application or the user removes them.  SignatureHTH, Kevin Spencer Chicken Salad Surgeon Microsoft MVP > Is it that no one uses the generated Settings class and user.config file? > [quoted text clipped - 17 lines] >> Thanks >> Steve My concern over using the registry or well know locations was with Vista security. I was unsure as to what it may or may not limit me to. Similarly, what about security policies that system administrators put in place. The user settings seemed to be a safe (Microsoft) way round this. What I've done for now is throw together my own class to wrap "ini" file functionality using an xml file. It allows me to control where the file goes and what it's called and I don't need to worry about application version numbers. I've used a "well known location" and am just hoping it won't get locked down by Vista. (It's the users Application Data folder - since, on reflection, I'm saving application data - folder locations - rather than pure user data.). I sacrifice strong typing using this method, but you can't have everything. Thanks Steve > Hi Steve, > [quoted text clipped - 27 lines] >>> Thanks >>> Steve Hi Steve, Considering your decision regarding approach, you could still use User Settings. All you would have to do is to copy the existing User Settings to your installation Settings file. It is, after all, just an XML file containing a serialized class. SignatureHTH, Kevin Spencer Chicken Salad Surgeon Microsoft MVP > My concern over using the registry or well know locations was with Vista > security. I was unsure as to what it may or may not limit me to. [quoted text clipped - 47 lines] >>>> Thanks >>>> Steve We rolled our own configuration manager in order to sustain the settings when we do updates. We are using ClickOnce deployment, so the config file is not part of the installation, it is created by the application when you run it (if it doesn't exist), and updated thereafter. We are outputting ours as XML, putting it in the user's profile folders down under LocalSettings, where we create a folder for our application's files. Hope that helps. RobinS. GoldMail, Inc. ------------------------------------------- > Is it that no one uses the generated Settings class and user.config file? > [quoted text clipped - 17 lines] >> Thanks >> Steve I am sure the procedure is the same for C#, or at least similar: ' ' Check if the settings need migrating from previous version ' If My.Settings.Current = False Then My.Settings.Upgrade() My.Settings.Current = True ' Done the upgrade End If Sid. > We rolled our own configuration manager in order to sustain the settings > when we do updates. [quoted text clipped - 34 lines] >>> Thanks >>> Steve Yes, I've seen that in VB. I don't know if C# has a corresponding, uh, "opportunity". It could be true. However, now what if your user wants to revert back a version, or if he uninstalls and reinstalls the application? For us, it gave us more functionality and flexibility to write out own config manager. It's not that much code; we used a dictionary to store the data in memory; we read it in when starting the app, write it out when anything gets updated. Good luck to all. RobinS. GoldMail, Inc. --------------------------------- >I am sure the procedure is the same for C#, or at least similar: > ' [quoted text clipped - 52 lines] >>>> Thanks >>>> Steve Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.