How to save user options and settings to a file, like we used to do with INI files?

  • Thread starter Richard Lewis Haggard
  • Start date
R

Richard Lewis Haggard

I have an application that can't use the registry to save various user
options and application settings. My first thought was to simply use an
application configuration file but this approach seems flawed. The app
config file appears to be updated with values while the application is
running but when the application closes, the file seems to get restored to a
pristine state and the accumulated user options and application settings are
discarded. What is the accepted way to persist application values to a file
in a WinForms 2 application?
 
M

Michael Nemtsev

Hello Richard Lewis Haggard" HaggardAtWorldDotStdDotCom,

R> The app config file appears to be updated with values while the
R> application is running but when the application closes, the file
R> seems to get restored to a pristine state and the accumulated user
R> options and application settings are discarded.

Emm, could u explain what do u mean? Why config is restored?

R> What is the accepted
R> way to persist application values to a file in a WinForms 2
R> application?

One of the approaches, besides xml config, is to use Isolation Storage

---
WBR,
Michael Nemtsev [C# MVP] :: blog: http://spaces.live.com/laflour

"At times one remains faithful to a cause only because its opponents do not
cease to be insipid." (c) Friedrich Nietzsch
 
R

Richard Lewis Haggard

Settings file? I saw that but was under the impression that it did not lend
itself well to addition and deletion of values programmatically. Did I
misunderstand? Because I thought that it would be difficult to write user
specific application options and MRU list, I deemed that approach
unreasonable. Have I unnecessarily exercised myself in jumping to this
conclusion?

Given that writing an indeterminate number of user specific values to some
sort of persistent storage is such a common requirement, one would have
thought that a consensus as to best practice would have been developed for
which I, only recently having been prized kicking and screaming from the MFC
dark ages, was unaware. I do thank you all for your patience while I flail
randomly about as I try to come up to speed.
--
Richard Lewis Haggard
www.Haggard-And-Associates.com

Dave Sexton said:
Hi Richard,

"Application Settings Overview"
http://msdn2.microsoft.com/en-us/library/k4s6c3a0.aspx

VS 2005 has built-in support for a single, Default Settings file and
Resources file, per project.
 
D

Dave Sexton

Hi Richard,
Settings file? I saw that but was under the impression that it did not
lend itself well to addition and deletion of values programmatically. Did
I misunderstand? Because I thought that it would be difficult to write
user specific application options and MRU list, I deemed that approach
unreasonable. Have I unnecessarily exercised myself in jumping to this
conclusion?

Yes :)

Take a look at the article I posted and you'll see that even controls can
use the Application Settings architecture. For example, ToolStrip uses
Application Settings to save position information of itself and its items
between application sessions.

The ApplicationSettingsBase class provides a Save method that you can call
from your application to persist data (the Save method is actually an
overridden form of the SettingsBase.Save method, from which it derives).
You can even create your own SettingsProvider for persistence outside of the
default local file storage.

Particular settings may be configured to have application-scope or
user-scope in WinForms applications and there is built-in support for
collections as well. IMO, this technology is perfect for persisting a raw
MRU list, per user, as long as the information being persisted isn't
sensitive data that must be secured (although simple, managed cryptography
would probably do the trick).
Given that writing an indeterminate number of user specific values to some
sort of persistent storage is such a common requirement, one would have
thought that a consensus as to best practice would have been developed for
which I, only recently having been prized kicking and screaming from the
MFC dark ages, was unaware. I do thank you all for your patience while I
flail randomly about as I try to come up to speed.

There are no explicitly stated "best practices" that I'm aware of since you
have to consider security, the quantity of the data and the type of the data
(e.g., relational, structured, raw text, raw binary) and because there are
many different places and ways to persist the data (e.g., Application
Settings, application configuration file, Isolated Storage, delimited
flat-file, RDBMS, structured storage, xml file, raw binary file containing a
serialized object-graph, etc.). Application Settings, in the 2.0 framework,
is usually sufficient, but I've seen applications use Isolated Storage, the
application configuration file, an xml file or an RDBMS such as Sql Server
2005 as well.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top