95

What approach do you recommend for persisting user settings in a WPF windows (desktop) application? Note that the idea is that the user can change their settings at run time, and then can close down the application, then when starting up the application later the application will use the current settings. Effectively then it will appear as if the application settings do not change.

Q1 - Database or other approach? I do have a sqlite database that I will be using anyway hence using a table in the database would be as good as any approach?

Q2 - If Database: What database table design? One table with columns for different data types that one might have (e.g. string, long, DateTime etc) OR just a table with a string for the value upon which you have to serialize and de-serialize the values? I'm thinking the first would be easier, and if there aren't many settings the overhead isn't much?

Q3 - Could Application Settings be used for this? If so are there any special tasks required to enable the persistence here? Also what would happen regarding usage of the "default" value in the Application Settings designer in this case? Would the default override any settings that were saved between running the application? (or would you need to NOT use the default value)

ouflak
  • 2,458
  • 10
  • 44
  • 49
Greg
  • 34,042
  • 79
  • 253
  • 454
  • 2
    **@All new users** It is preferred if you can post separate questions instead of combining your questions into one. That way, it helps the people answering your question and also others hunting for at least one of your questions. Thanks! – Hille Sep 18 '19 at 06:38

10 Answers10

90

You can use application settings for this, using a database is not the best option considering the time consumed to read and write the settings (especially if you use web services).

Here are few links which explain how to achieve this and use settings in WPF:

Todd West
  • 326
  • 1
  • 8
akjoshi
  • 15,374
  • 13
  • 103
  • 121
30

Update: Nowadays I would use JSON.

I also prefer to go with serialization to file. XML files fits mostly all requirements. You can use the ApplicationSettings build in but those have some restrictions and a defined but (for me) very strange behavior where they stored. I used them a lot and they work. But if you want to have full control how and where they stored I use another approach.

  1. Make a class Somewhere with all your settings. I named it MySettings
  2. Implement Save and Read for persistence
  3. Use them in you application-code

Advantages:

  • Very Simple approach.
  • One Class for Settings. Load. Save.
  • All your Settings are type safe.
  • You can simplify or extend the logic to your needs (Versioning, many Profiles per User, etc.)
  • It works very well in any case (Database, WinForms, WPF, Service, etc...)
  • You can define where to store the XML files.
  • You can find them and manipulate them either by code or manual
  • It works for any deployment method I can imagine.

Disadvantages: - You have to think about where to store your settings files. (But you can just use your installation folder)

Here is a simple example (not tested)-

public class MySettings
{
    public string Setting1 { get; set; }
    public List<string> Setting2 { get; set; }

    public void Save(string filename)
    {
        using (StreamWriter sw = new StreamWriter(filename))
        {
            XmlSerializer xmls = new XmlSerializer(typeof(MySettings));
            xmls.Serialize(sw, this);
        }
    }
    public MySettings Read(string filename)
    {
        using (StreamReader sw = new StreamReader(filename))
        {
            XmlSerializer xmls = new XmlSerializer(typeof(MySettings));
            return xmls.Deserialize(sw) as MySettings;
        }
    }
}

And here is how to use it. It's possible to load default values or override them with the user's settings by just checking if user settings exist:

public class MyApplicationLogic
{
    public const string UserSettingsFilename = "settings.xml";
    public string _DefaultSettingspath = 
        Assembly.GetEntryAssembly().Location + 
        "\\Settings\\" + UserSettingsFilename;

    public string _UserSettingsPath = 
        Assembly.GetEntryAssembly().Location + 
        "\\Settings\\UserSettings\\" + 
        UserSettingsFilename;

    public MyApplicationLogic()
    {
        // if default settings exist
        if (File.Exists(_UserSettingsPath))
            this.Settings = Settings.Read(_UserSettingsPath);
        else
            this.Settings = Settings.Read(_DefaultSettingspath);
    }
    public MySettings Settings { get; private set; }

    public void SaveUserSettings()
    {
        Settings.Save(_UserSettingsPath);
    }
}

maybe someone get's inspired by this approach. This is how I do it now for many years and I'm quite happy with that.

Mat
  • 1,960
  • 5
  • 25
  • 38
  • 1
    For the disadvantage, it would be that you don't have the settings designer anymore so it is a bit less user friendly when both would works. – Phil1970 Dec 02 '16 at 19:51
  • 4
    Totally agree on the "very strange behavior where they are stored", I'm using your approach precisely because of this. +1. – Hannish Apr 24 '17 at 12:25
  • If you have a NEW question, please ask it by clicking the [Ask Question](//stackoverflow.com/questions/ask) button. – Mat Oct 24 '18 at 13:50
12

You can store your settings info as Strings of XML in the Settings.Default. Create some classes to store your configuration data and make sure they are [Serializable]. Then, with the following helpers, you can serialize instances of these objects--or List<T> (or arrays T[], etc.) of them--to String. Store each of these various strings in its own respective Settings.Default slot in your WPF application's Settings.

To recover the objects the next time the app starts, read the Settings string of interest and Deserialize to the expected type T (which this time must be explcitly specified as a type argument to Deserialize<T>).

public static String Serialize<T>(T t)
{
    using (StringWriter sw = new StringWriter())
    using (XmlWriter xw = XmlWriter.Create(sw))
    {
        new XmlSerializer(typeof(T)).Serialize(xw, t);
        return sw.GetStringBuilder().ToString();
    }
}

public static T Deserialize<T>(String s_xml)
{
    using (XmlReader xw = XmlReader.Create(new StringReader(s_xml)))
        return (T)new XmlSerializer(typeof(T)).Deserialize(xw);
}
Glenn Slayden
  • 17,543
  • 3
  • 114
  • 108
6

Apart from a database, you can also have following options to save user related settings

  1. registry under HKEY_CURRENT_USER

  2. in a file in AppData folder

  3. using Settings file in WPF and by setting its scope as User

marc_s
  • 732,580
  • 175
  • 1,330
  • 1,459
ajay_whiz
  • 17,573
  • 4
  • 36
  • 44
  • 4
    Suggestion 1 is the reason why Applications slow down Windows, better not fill up registry keys with something better done in a file IMO. – quadroid Nov 04 '14 at 13:27
  • 1
    @Console, writing file on a disk slow downs (wear off) SSD, writing data in database slow downs database. What is your option then? Windows registry is *intended* to be used as one of places to save *settings*. – Sinatr Nov 07 '14 at 09:21
  • 1
    You are right it is, i think it is important to mention that registry has some drawbacks if every application saves hunderd user preferences there. – quadroid Nov 07 '14 at 10:09
  • 1
    @Sinatr Originally, the registry was intended for that purpose... but it was not design to handle large amount of data so at some point in the history, Microsoft has recommended to stop using it. As far as I know, Windows load the whole registry on logon and would also make copy either for roaming or to be able to load last known good configuration after a major crash. Thus using the registry affect the system even if the application is never used. – Phil1970 Dec 02 '16 at 20:14
  • Also the registry has a size limit and if it was still used by application, probably that the limit would be exceeded on most computers. The registry was designed at a time where system has less memory in MB than computer has today in GB. The registry was not designed to be so large and thus even though that the limits have increased, it is not optimized for our current needs. – Phil1970 Dec 02 '16 at 20:20
6

The long running most typical approach to this question is: Isolated Storage.

Serialize your control state to XML or some other format (especially easily if you're saving Dependency Properties with WPF), then save the file to the user's isolated storage.

If you do want to go the app setting route, I tried something similar at one point myself...though the below approach could easily be adapted to use Isolated Storage:

class SettingsManager
{
    public static void LoadSettings(FrameworkElement sender, Dictionary<FrameworkElement, DependencyProperty> savedElements)
    {
        EnsureProperties(sender, savedElements);
        foreach (FrameworkElement element in savedElements.Keys)
        {
            try
            {
                element.SetValue(savedElements[element], Properties.Settings.Default[sender.Name + "." + element.Name]);
            }
            catch (Exception ex) { }
        }
    }

    public static void SaveSettings(FrameworkElement sender, Dictionary<FrameworkElement, DependencyProperty> savedElements)
    {
        EnsureProperties(sender, savedElements);
        foreach (FrameworkElement element in savedElements.Keys)
        {
            Properties.Settings.Default[sender.Name + "." + element.Name] = element.GetValue(savedElements[element]);
        }
        Properties.Settings.Default.Save();
    }

    public static void EnsureProperties(FrameworkElement sender, Dictionary<FrameworkElement, DependencyProperty> savedElements)
    {
        foreach (FrameworkElement element in savedElements.Keys)
        {
            bool hasProperty =
                Properties.Settings.Default.Properties[sender.Name + "." + element.Name] != null;

            if (!hasProperty)
            {
                SettingsAttributeDictionary attributes = new SettingsAttributeDictionary();
                UserScopedSettingAttribute attribute = new UserScopedSettingAttribute();
                attributes.Add(attribute.GetType(), attribute);

                SettingsProperty property = new SettingsProperty(sender.Name + "." + element.Name,
                    savedElements[element].DefaultMetadata.DefaultValue.GetType(), Properties.Settings.Default.Providers["LocalFileSettingsProvider"], false, null, SettingsSerializeAs.String, attributes, true, true);
                Properties.Settings.Default.Properties.Add(property);
            }
        }
        Properties.Settings.Default.Reload();
    }
}

.....and....

  Dictionary<FrameworkElement, DependencyProperty> savedElements = new Dictionary<FrameworkElement, DependencyProperty>();

public Window_Load(object sender, EventArgs e) {
           savedElements.Add(firstNameText, TextBox.TextProperty);
                savedElements.Add(lastNameText, TextBox.TextProperty);

            SettingsManager.LoadSettings(this, savedElements);
}

private void Window_Closing(object sender, System.ComponentModel.CancelEventArgs e)
        {
            SettingsManager.SaveSettings(this, savedElements);
        }
Jeff
  • 35,755
  • 15
  • 108
  • 220
3

In my experience storing all the settings in a database table is the best solution. Don't even worry about performance. Today's databases are fast and can easily store thousands columns in a table. I learned this the hard way - before I was serilizing/deserializing - nightmare. Storing it in local file or registry has one big problem - if you have to support your app and computer is off - user is not in front of it - there is nothing you can do.... if setings are in DB - you can changed them and viola not to mention that you can compare the settings....

Adam
  • 31
  • 1
  • And storing them remotely also has one big problem when the connection is not available... Many applications written to works online have a less than ideal experience when working offline or sometime even have bugs that make some functionality to not work offline even if it should not have any impact other than "spying" how the device is used. – Phil1970 Dec 02 '16 at 20:25
  • In some scenarios, there are some repeated list data, which is very consistent with the database table. But in some scenarios, in addition to the above-mentioned duplicate data, there are also some single user settings. In this case, if a table is used to store them, then this table has only one row of data, which makes me feel strange. How do you think about this? – huang Aug 18 '22 at 13:40
2

You can use SQLite, a small, fast, self-contained, full-featured, SQL database engine. I personally recommend it after trying settings file and XML file approach.

Install NuGet package System.Data.SQLite which is an ADO.NET provider for SQLite. The package includes support for LINQ and Entity Framework Overall you can do many things with such supporting features to your settings window.

1.Install SQLite 2.Create your database file 3.Create tables to save your settings 4.Access database file in your application to read and edit settings.

I felt this approach very much helpful for application settings, since i can do adjustments to database and also take advantage of ADO.Net and LINQ features

1

I typically do this sort of thing by defining a custom [Serializable] settings class and simply serializing it to disk. In your case you could just as easily store it as a string blob in your SQLite database.

akjoshi
  • 15,374
  • 13
  • 103
  • 121
Doobi
  • 4,844
  • 1
  • 22
  • 17
0
  1. In all the places I've worked, database has been mandatory because of application support. As Adam said, the user might not be at his desk or the machine might be off, or you might want to quickly change someone's configuration or assign a new-joiner a default (or team member's) config.

  2. If the settings are likely to grow as new versions of the application are released, you might want to store the data as blobs which can then be deserialized by the application. This is especially useful if you use something like Prism which discovers modules, as you can't know what settings a module will return. The blobs could be keyed by username/machine composite key. That way you can have different settings for every machine.

  3. I've not used the in-built Settings class much so I'll abstain from commenting. :)

marc_s
  • 732,580
  • 175
  • 1,330
  • 1,459
0

I wanted to use an xml control file based on a class for my VB.net desktop WPF application. The above code to do this all in one is excellent and set me in the right direction. In case anyone is searching for a VB.net solution here is the class I built:

Imports System.IO
Imports System.Xml.Serialization

Public Class XControl

Private _person_ID As Integer
Private _person_UID As Guid

'load from file
Public Function XCRead(filename As String) As XControl
    Using sr As StreamReader = New StreamReader(filename)
        Dim xmls As New XmlSerializer(GetType(XControl))
        Return CType(xmls.Deserialize(sr), XControl)
    End Using
End Function

'save to file
Public Sub XCSave(filename As String)
    Using sw As StreamWriter = New StreamWriter(filename)
        Dim xmls As New XmlSerializer(GetType(XControl))
        xmls.Serialize(sw, Me)
    End Using
End Sub

'all the get/set is below here

Public Property Person_ID() As Integer
    Get
        Return _person_ID
    End Get
    Set(value As Integer)
        _person_ID = value
    End Set
End Property

Public Property Person_UID As Guid
    Get
        Return _person_UID
    End Get
    Set(value As Guid)
        _person_UID = value
    End Set
End Property

End Class
Scott
  • 143
  • 1
  • 9