Resolved Persisting Values

[IanBr]

Hi, I'm very new to C# although I have spent over 20 years programming in other languages, so please excuse any 'simplistic' questions!

I am currently trying to find the best way to persist values from one program run to the next. Values I'm thinking of are such things as form positions and sizes, colours, font details, all sorts of things like that which I would like to reinstate each run, possibly lots of values.

In the old days I'd put them in an ini, these days more likely an xml file but it struck me that there may be a built in way to save and restore such values. I don't want to store them in the Registry because I want them available, visible and editable, just in case!

Any advice most welcome.

Thanks

 

[jmcilhinney]

Assuming that you're talking about Windows Forms and .NET Framework, there is a built-in way, but you might need a little extra code for some properties.

If you open the Settings page of the project properties, you can create settings that there are akin to what you may have previously stored in an INI file or the Registry. If you select Application scope then there is one value for the entire application and that is stored in the primary config file. That config file will be named App.config in your project but then renamed when it is copied on a build, e.g. to MyProject.exe.config. If you select User scope, the default value is stored in the primary config file but each Windows user will have their own current values stored in a user config file under their personal folder.

Both Application- and User-scoped settings can be accessed in code via Properties.Settings.Default. Existing data is loaded automatically, accessible via properties of that object and can be saved after any changes are made. Application-scoped setting are read-only via that object, although they can be edited via the Configuration system if the current user is an administrator. User-scoped settings are read/write.

Many properties of your forms and their controls can be bound to User-scoped settings, so they will be automatically loaded at startup and persisted when you save your settings. You can create the setting first and then bind to it or create the binding and the setting at the same time. In the WinForms designer, select your form or control, open the Properties window, select the (ApplicationSettings) node and then browse it. You'll be presented with a list of bindable properties and you can select an existing setting of the appropriate type or create a new one. For those properties not listed, binding is not possible but you can still create your own properties and then load the appropriate values on the Load event of the form and save them on the FormClosed or FormClosing event. FormClosed would be logically better but I'm not 100% sure that all the properties you might want to save would still be set at the point. I think they would be but you ought to test to be sure.

 

[jmcilhinney]

Note that these property bindings are not available for WPF apps and I don't think they are supported by .NET Core (including .NET 5.0) projects at present. You should be handling your binding via view models in WPF anyway and .NET Core can still use settings but you'd have to move the data back and forth manually.

 

[IanBr]

Assuming that you're talking about Windows Forms and .NET Framework, there is a built-in way, but you might need as alittle extra code for some properties.

If you open the Settings page of the project properties, you can create settings that there are akin to what you may have previously stored in an INI file or the Registry. If you select Application scope then there is one value for the entire application and that is stored in the primary config file. That config file will be named App.config in your project but then renamed when it is copied on a build, e.g. to MyProject.exe.config. If you select User scope, the default value is stored in the primary config file but each Windows user will have their own current values stored in a user config file under their personal folder.

Both Application- and User-scoped settings can be accessed in code via Properties.Settings.Default. Existing data is loaded automatically, accessible via properties of that object and can be saved after any changes are made. Application-scoped setting are read-only via that object, although they can be edited via the Configuration system if the current user is an administrator. User-scoped settings are read/write.

Many properties of your forms and their controls can be bound to User-scoped settings, so they will be automatically loaded at startup and persisted when you save your settings. You can create the setting first and then bind to it or create the binding and the setting at the same time. In the WinForms designer, select your form or control, open the Properties window, select the (ApplicationSettings) node and then browse it. You'll be presented with a list of bindable properties and you can select an existing setting of the appropriate type or create a new one. For those properties not listed, binding is not possible but you can still create your own properties and then load the appropriate values on the Load event of the form and save them on the FormClosed or FormClosing event. FormClosed would be logically better but I'm not 100% sure that all the properties you might want to save would still be set at the point. I think they would be but you ought to test to be sure.

Thank you very much for your detailed reply, that's just what I wanted. I had hoped there was a method like this which is similar to that used by VB.net but I've never heard of this automatic persistence before and I'm going to have to experiment with that. I'm a little unsure about exactly where the values are stored, it sounds like it's somewhere below Appdata which I'm not keen on mainly because Microsoft in their infinite wisdom made it a hidden folder, never understood why but I can live with that.
Thanks again

 

[Skydiver]

You can override the location of the settings by providing your own LocalFileSettingsProvider implementation according to the documentation:

By default, all client-based applications use the LocalFileSettingsProvider to provide storage. If an alternate settings provider is desired, then the wrapper class or property must be decorated with a corresponding SettingsProviderAttribute.