How to change the predefined userconfig directory of my .NET application?

Question

Currentlly the user-settings of my application are stored in this default directory:

C:\Users\{User Name}\AppData\Roaming\{Company Name}\{Assembly Name}.vshos_Url_{Hash}\{Assembly Version}

I'm aware of the meaning of the default Microsoft naming rules, my question is: How can I change that defaut folder at execution time or by modifying the appconfig file?.

My intention is only be able to handle the directory on which the user-settings of my application will be saved, for example I would like to save the user-settings file in this directory:

C:\Users\{User Name}\AppData\Roaming\{Assembly Name}

I know this is possible to acchieve, because I've seen much .NET applications that can store its userconfig file in a custom Roaming folder that doesn't follows the Microsoft default rules with that unhandled hash and those other annonying naming rules.

Answer 1

That naming convention exists so that NET can be sure the correct settings are be loaded. Since you have yielded control of managing settings to the NET Framework/VB Application Framework, it also takes on the responsibility of making sure that an app is loading the right set of settings. That being the case, the evidence hash is used to uniquely identify one WindowsApplication1 from another (among other things).

I know this is possible to acchieve, because I've seen much .NET applications that can store its userconfig file in a custom Roaming folder

It is possible, but I am not sure everything is quite the way you conclude. I very seriously doubt that many apps go thru the hassle to implement a custom provider when they could much more easily save an XML file to that location using a custom settings class.

The Simple Solution

Write your own user options class, and serialize it yourself. For instance a Shared/static method can be used to deserialize the class in very little code (this just happens to use JSON):

Friend Shared Function Load() As UserOptions
    ' create instance for default on new install 
    Dim u As New UserOptions

    If File.Exists(filePath) Then
        ' filepath can be anywhere you have access to!
        Dim jstr = File.ReadAllText(filePath)
        If String.IsNullOrEmpty(jstr) = False Then
            u = JsonConvert.DeserializeObject(Of UserOptions)(jstr)
        End If
    End If

    Return u
End Function

The app implementing it:

UOpt = UserOptions.Load()

Among the Pros , you have total control over where the file is saved, and can use any serializer you like. Most of all, it is simple - much less code than presented below.

The Cons are that the code using it would have to manually Load and Save them (easily handled in Application events), and there is no fancy designer for it.

The Long and Winding Road: a Custom SettingsProvider

A custom SettingsProvider will allow you to change how settings are handled, saved and loaded, including changing the folder location.

This question is narrowly focused on changing the file location. The problem is that there is not a (clean, easy) way for your app to talk to your SettingsProvider in order to specify a folder. The provider needs to be able to work that out internally and of course be consistent.

Most people will want to do more than just change the folder name used. For instance, in playing around, in place of XML I used a SQLite database which mirrored a structure the code uses. This made it very easy to load local and the correct roaming values. Were that approach taken all the way, the code could be greatly simplified and quite possibly the whole Upgrade process. So this provider takes some of those wider needs into account.

There are 2 key considerations even though you just want to change the filename:

Local vs Roaming

Coding the provider to always store in AppData\\Roaming but write unqualified local settings there would be irresponsible. Distinguishing between them is a capability that ought not be sacrificed in order to elide the evidence hash in the folder name.

Note: Each Setting can be set as a Roaming or Local value: with a Setting selected in the Settings Editor, open the Properties pane - change Roaming to True.

There seems to be a consensus in the (very) few questions here dealing with a custom SettingsProvider to save Local and Roaming to the same file but in different sections. That makes a great deal of sense - and is simpler than loading from 2 files - so the XML structure used is:

<configuration>
  <CommonShared>
    <setting name="FirstRun">True</setting>
    <setting name="StartTime">15:32:18</setting>
    ...
  </CommonShared>
  <MACHINENAME_A>
    <setting name="MainWdwLocation">98, 480</setting>
    <setting name="myGuid">d62eb904-0bb9-4897-bb86-688d974db4a6</setting>
    <setting name="LastSaveFolder">C:\Folder ABC</setting>
  </MACHINENAME_A>
  <MACHINENAME_B>
    <setting name="MainWdwLocation">187, 360</setting>
    <setting name="myGuid">a1f8d5a5-f7ec-4bf9-b7b8-712e80c69d93</setting>
    <setting name="LastSaveFolder">C:\Folder XYZ</setting>
  </MACHINENAME_B>
</configuration>

The roaming items are stored in sections named after the MachineName they are used on. There might be some value in retaining the <NameSpace>.My.MySettings node, but I am not sure what purpose it serves.

I removed the SerializeAs element since it is not used.

Versions

Nothing whatsoever will happen if you invoke My.Settings.Upgrade . Even though it is a Settings method, it is actually something in ApplicationSettingsBase , so your provider isn't involved.

As a result, using the full version string as part of the folder causes a problem if you auto increment the last element. Trivial rebuilds will create a new folder and lose and orphan the old settings. Perhaps you could look for and load the values for a previous version when there is no current file. Then perhaps delete that old file/folder, so there is always only one possible set of old settings. Feel free to add oodles and oodles of merge code.

For the primary purpose of just changing the data store folder, I removed the version folder segment. When using a global provider the code automatically accumulates settings. A settings which has been removed wont "leak" into the app because NET wont ask for a value for it. The only issue is that there will be a value for it in the XML.

I added code to purge these. This will prevent a problem should you later reuse a settings name with a different type. The old saved value for Foo as Decimal wont work with the new Foo as Size for instance. Things will still go badly if you radically change a type. Don't do that.

---

This answer Custom path of the user.config provides a very nice starting point for a custom provider. It has a few problems and is missing a few things but provides a quick start guide for some of the steps and boilerplate code typical of any provider. Since many people may need to further modify the provider here, it might be worth reading (and upvoting).

The code here borrows a few things from that answer and:

• Adds various refinements
• Provides for a custom path
• Detection for settings set as Roaming
• Local and Roaming section in the file
• Proper handling of complex types such as Point or Size
• Detect and prune removed settings
• is in VB

1. Setup

For the most part, you can't incrementally write/debug this - little will work until you are done.

• Add a reference to System.Configuration
• Add a new class to your project

Example:

Imports System.Configuration 
Public Class CustomSettingsProvider
    Inherits SettingsProvider
End Class

Next, go to the Settings designer and add some settings for testing. Tag some as Roaming for a complete test. Then click the <> View Code button shown here:

Everyone loves freehand circles!

There are apparently two ways to implement a custom provider. The code here will use yours in place of My.MySettings . You can also specify a custom provider on a per-Setting basis by typing the provider name in the Properties pane, and skip the rest of this step. I did not test this, but it is how it is supposed to work.

In order to use the new settings provider "you" write, it needs to be associated with MySettings using an attribute:

Imports System.Configuration 

<SettingsProvider(GetType(ElectroZap.CustomSettingsProvider))>
Partial Friend NotInheritable Class MySettings
End Class

'ElektroZap' is your root NameSpace, and 'ElektroApp' is your app name, by the way. The code in the constructor can be changed to use the Product name or module name.

We are done with that file; save it and close it.

2. SettingsProvider

First, note that this CustomProvider is generic and should work with any app by just designating it as the SettingsProvider . But it really only does 2 things:

• Uses a custom path
• Merges local and roaming settings into one file

Typically one would have a longer ToDo list before resorting to a custom provider, so for many this may just provide the starting point for Other Things. Keep that in mind that some changes may make it specific to a project.

---

One of the things added is support for the more complex types such as Point or Size . These are serialized as invariant strings so that they can be parsed back. What that means is this:

Console.WriteLine(myPoint.ToString())

The result, {X=64, Y=22} cannot be directly converted back and Point lacks a Parse/TryParse method. Using the invariant string form 64,22 allows it to be converted back to the correct type. The original linked code simply used:

Convert.ChangeType(setting.DefaultValue, t);

This will work with simple types, but not Point , Font etc. I can't recall for sure, but I think this is a simple mistake of using SettingsPropertyValue.Value rather than .SerializedValue .

3. The Code

Public Class CustomSettingsProvider
    Inherits SettingsProvider

    ' data we store for each item
    Friend Class SettingsItem
        Friend Name As String
        'Friend SerializeAs As String           ' not needed
        Friend Value As String
        Friend Roamer As Boolean
        Friend Remove As Boolean                ' mutable
        'Friend VerString As String             ' ToDo (?)
    End Class

    ' used for node name
    Private thisMachine As String

    ' loaded XML config
    'Private xDoc As XDocument
    Private UserConfigFilePath As String = ""
    Private myCol As Dictionary(Of String, SettingsItem)


    Public Sub New()
        myCol = New Dictionary(Of String, SettingsItem)

        Dim asm = Assembly.GetExecutingAssembly()
        Dim verInfo = FileVersionInfo.GetVersionInfo(asm.Location)
        Dim Company = verInfo.CompanyName
        ' product name may have no relation to file name...
        Dim ProdName = verInfo.ProductName

        ' use this for assembly file name:
        Dim modName = Path.GetFileNameWithoutExtension(asm.ManifestModule.Name)
        ' dont use FileVersionInfo;
        ' may want to omit the last element
        'Dim ver = asm.GetName.Version


        '  uses `SpecialFolder.ApplicationData`
        '    since it will store Local and Roaming val;ues
        UserConfigFilePath = Path.Combine(GetFolderPath(SpecialFolder.ApplicationData),
                                      Company, modName,
                                       "user.config")

        ' "CFG" prefix prevents illegal XML, 
        '    the FOO suffix is to emulate a different machine
        thisMachine = "CFG" & My.Computer.Name & "_FOO"

    End Sub

    ' boilerplate
    Public Overrides Property ApplicationName As String
        Get
            Return Assembly.GetExecutingAssembly().ManifestModule.Name
        End Get
        Set(value As String)

        End Set
    End Property

    ' boilerplate
    Public Overrides Sub Initialize(name As String, config As Specialized.NameValueCollection)
        MyBase.Initialize(ApplicationName, config)
    End Sub

    ' conversion helper in place of a 'Select Case GetType(foo)'
    Private Shared Conversion As Func(Of Object, Object)

    Public Overrides Function GetPropertyValues(context As SettingsContext,
                                                collection As SettingsPropertyCollection) As SettingsPropertyValueCollection
        ' basically, create a Dictionary entry for each setting,
        ' store the converted value to it
        ' Add an entry when something is added
        '
        ' This is called the first time you get a setting value
        If myCol.Count = 0 Then
            LoadData()
        End If

        Dim theSettings = New SettingsPropertyValueCollection()
        Dim tValue As String = ""

        ' SettingsPropertyCollection is like a Shopping list
        ' of props that VS/VB wants the value for
        For Each setItem As SettingsProperty In collection
            Dim value As New SettingsPropertyValue(setItem)
            value.IsDirty = False

            If myCol.ContainsKey(setItem.Name) Then
                value.SerializedValue = myCol(setItem.Name)
                tValue = myCol(setItem.Name).Value
            Else
                value.SerializedValue = setItem.DefaultValue
                tValue = setItem.DefaultValue.ToString
            End If

            ' ToDo: Enums will need an extra step
            Conversion = Function(v) TypeDescriptor.
                                    GetConverter(setItem.PropertyType).
                                    ConvertFromInvariantString(v.ToString())

            value.PropertyValue = Conversion(tValue)
            theSettings.Add(value)
        Next

        Return theSettings
    End Function

    Public Overrides Sub SetPropertyValues(context As SettingsContext,
                                           collection As SettingsPropertyValueCollection)
        ' this is not called when you set a new value
        ' rather, NET has one or more changed values that
        ' need to be saved, so be sure to save them to disk
        Dim names As List(Of String) = myCol.Keys.ToList
        Dim sItem As SettingsItem

        For Each item As SettingsPropertyValue In collection
            sItem = New SettingsItem() With {
                                .Name = item.Name,
                                .Value = item.SerializedValue.ToString(),
                                .Roamer = IsRoamer(item.Property)
                            }
            '.SerializeAs = item.Property.SerializeAs.ToString(),

            names.Remove(item.Name)
            If myCol.ContainsKey(sItem.Name) Then
                myCol(sItem.Name) = sItem
            Else
                myCol.Add(sItem.Name, sItem)
            End If
        Next

        ' flag any no longer used
        ' do not use when specifying a provider per-setting!
        For Each s As String In names
            myCol(s).Remove = True
        Next

        SaveData()
    End Sub

    ' detect if a setting is tagged as Roaming
    Private Function IsRoamer(prop As SettingsProperty) As Boolean
        Dim r = prop.Attributes.
                    Cast(Of DictionaryEntry).
                    FirstOrDefault(Function(q) TypeOf q.Value Is SettingsManageabilityAttribute)

        Return r.Key IsNot Nothing
    End Function

    Private Sub LoadData()
        ' load from disk
        If File.Exists(UserConfigFilePath) = False Then
            CreateNewConfig()
        End If

        Dim xDoc = XDocument.Load(UserConfigFilePath)
        Dim items As IEnumerable(Of XElement)
        Dim item As SettingsItem

        items = xDoc.Element(CONFIG).
                             Element(COMMON).
                             Elements(SETTING)

        ' load the common settings
        For Each xitem As XElement In items
            item = New SettingsItem With {.Name = xitem.Attribute(ITEMNAME).Value,
                                          .Roamer = False}
            '.SerializeAs = xitem.Attribute(SERIALIZE_AS).Value,

            item.Value = xitem.Value
            myCol.Add(item.Name, item)
        Next

        ' First check if there is a machine node
        If xDoc.Element(CONFIG).Element(thisMachine) Is Nothing Then
            ' nope, add one
            xDoc.Element(CONFIG).Add(New XElement(thisMachine))
        End If
        items = xDoc.Element(CONFIG).
                            Element(thisMachine).
                            Elements(SETTING)

        For Each xitem As XElement In items
            item = New SettingsItem With {.Name = xitem.Attribute(ITEMNAME).Value,
                                          .Roamer = True}
            '.SerializeAs = xitem.Attribute(SERIALIZE_AS).Value,

            item.Value = xitem.Value
            myCol.Add(item.Name, item)
        Next
        ' we may have changed the XDOC, by adding a machine node 
        ' save the file
        xDoc.Save(UserConfigFilePath)
    End Sub

    Private Sub SaveData()
        ' write to disk

        Dim xDoc = XDocument.Load(UserConfigFilePath)
        Dim roamers = xDoc.Element(CONFIG).
                           Element(thisMachine)

        Dim locals = xDoc.Element(CONFIG).
                          Element(COMMON)

        Dim item As XElement
        Dim section As XElement

        For Each kvp As KeyValuePair(Of String, SettingsItem) In myCol
            If kvp.Value.Roamer Then
                section = roamers
            Else
                section = locals
            End If

            item = section.Elements().
                        FirstOrDefault(Function(q) q.Attribute(ITEMNAME).Value = kvp.Key)

            If item Is Nothing Then
                ' found a new item
                Dim newItem = New XElement(SETTING)
                newItem.Add(New XAttribute(ITEMNAME, kvp.Value.Name))
                'newItem.Add(New XAttribute(SERIALIZE_AS, kvp.Value.SerializeAs))
                newItem.Value = If(String.IsNullOrEmpty(kvp.Value.Value), "", kvp.Value.Value)
                section.Add(newItem)
            Else
                If kvp.Value.Remove Then
                    item.Remove()
                Else
                    item.Value = If(String.IsNullOrEmpty(kvp.Value.Value), "", kvp.Value.Value)
                End If
            End If

        Next
        xDoc.Save(UserConfigFilePath)

    End Sub

    ' used in the XML
    Const CONFIG As String = "configuration"
    Const SETTING As String = "setting"
    Const COMMON As String = "CommonShared"
    Const ITEMNAME As String = "name"
    'Const SERIALIZE_AS As String = "serializeAs"

    ' https://stackoverflow.com/a/11398536
    Private Sub CreateNewConfig()
        Dim fpath = Path.GetDirectoryName(UserConfigFilePath)
        Directory.CreateDirectory(fpath)

        Dim xDoc = New XDocument
        xDoc.Declaration = New XDeclaration("1.0", "utf-8", "true")
        Dim cfg = New XElement(CONFIG)

        cfg.Add(New XElement(COMMON))
        cfg.Add(New XElement(thisMachine))

        xDoc.Add(cfg)
        xDoc.Save(UserConfigFilePath)
    End Sub

End Class

That's a lot of code just to elide the evidence hash from the path, but it is what MS recommends. It is also likely the only way: the property in ConfigurationManager which gets the file is read only and it backed by code.

Results:

The actual XML is as shown earlier with local/common and machine specific sections. I used several different app names and such testing various things:

Ignore the version portion. As noted earlier that has been removed. Otherwise the folders are correct - as noted above you have some options when it comes to the AppName segment.

Important Notes

• The Load methods in your provider are not called unless and until the related app accesses a Settings property
• Once loaded, the Save method will be called when the app ends (using the VB Framework) whether or not the code changes anything
• NET seems to only save settings which are different from the default value. When using a custom provider, all the values are marked IsDirty as true and UsingDefaultValue as false.
• If/when loaded, all the values are returned and NET simply gets values from that collection thru the life of the app

My main concern was the correct conversion of types and local/roaming support. I did not check every single possible Type . In particular, custom types and enums (I know enums will need extra handling).

---

It is worth noting that using a DataTable makes this much simpler. You do not need the SettingsItem class, the collection, no XDoc (use .WriteXML / .ReadXml ). All the code to create and organize XElements also goes away.

The resulting XML file is different, but that is just form following function. About 60 lines of code in all can be removed, and it is just simpler.

Resources

• SettingsProvider Class
• MSDN blog entry about Settings
• Stackoverflow: Custom path of the user.config "Chuck" uses better named scratch variables
• Stackoverflow: MachineName problems in XML
• I didnt see this CodeProject article until I was done: Creating a Custom Settings Provider This appears to be a different approach using a custom provider on a per-setting basis.

Answer 2

I've seen many issues around this, eg: https://stackoverflow.com/a/15726277/495455

To do anything special its much easier to use XDoc or LinqXML with your own config file(s).

This way you can save them where ever you like and you dont encounter other issues, eg: Custom Configuration Section can only be saved/modified while running as administrator?