User Settings

[Steve Barnett]

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

 

[Steve Barnett]

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

 

[Peter Duniho]

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

 

[Kevin Spencer]

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.

--
HTH,

Kevin Spencer
Chicken Salad Surgeon
Microsoft MVP

 

[Steve Barnett]

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

 

[Kevin Spencer]

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.

--
HTH,

Kevin Spencer
Chicken Salad Surgeon
Microsoft MVP

 

[RobinS]

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.
-------------------------------------------

 

[Sid Price]

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.

 

[RobinS]

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.
---------------------------------