Client Settings FAQ posted

We have been getting lots of feedback on the new Whidbey Settings feature that I have blogged about in the past. Since there are a set of questions many people ask as they begin to delve into the API, I thought it might be useful to post an FAQ that I can point folks to that should answer most of these questions. I posted this as an article instead of a regular blog post so I can update it off and on in the future.

If you have any suggestions for questions to add to the FAQ, please feel free to leave a comment here.

Comments (68)

  1. MDeevi says:

    Hi Prabhu,

    I had seen your "client settings" blog from part1 to part3, in all of these you are explaining about the ApplicationSettingsBase but I want to write my own custom SettingsProvider class. please help me out in

    How to write a custom SettingsProvider class?I am asking this question as we could not able to get any links explaining it in better way. If you can provide any samples that will be helpful and also please provide us a solution how to set this custom SettingsProvider to the application, so that application reads the settings from the custom SettingsProvider rather than default LocalFileSettingsProvider



  2. rprabhu says:

    There are a couple of sample SettingsProvider implementations in the Beta 2 SDK samples. These should get you started. Let me know if you could not find them.

  3. MDeevi says:

    Sorry! Prabhu, I could not able to find the samples in Beta2 SDK. Can u please get me the links or sample code so that i will try to change according to our requirement.



  4. rprabhu says:

    They are located in the .Net SDK documentation under .Net Framework SDK / Samples and QuickStarts / Samples / Technology Samples / Windows Forms Controls Samples.

    Binding to Client Settings Sample

    Demonstrates how to bind to application settings to reflect user changes.

    Client Settings Web Service Client Sample

    Shows how to use a Web service client to change application settings.

    RegistrySettingsProvider Sample

    Demonstrates how to persist application settings in the registry.

  5. MDeevi says:

    Thanks Prabhu, Got the path for samples and could able to write custom SettingsProvider class. But there is a problem we are getting an error saying that

    "Failed to load provider type: MyCustomSettingsProvider"

    I configured my settingsprovider in the following way in Settings.CS file as

    [SettingsProvider("MyCustomSettingsProvider", "MyCustomSettingsProvider")]

    class Settings : ApplicationSettingsBase


    . . . . . .

    . . . . . .


    Please try to help me out how to get rid of this error.



  6. rprabhu says:

    You need to provide an assembly qualified type name to the attribute, something like:

    [SettingsProvider("MyCustomSettingsProvider, MyAssembly, Version=…")]

    (replace … with full assembly information)

    Alternately, it is easier to use the other overload that takes a type:


  7. MDeevi says:

    Thanks Prabhu for your quick response. Its working fine when I changed that to

    [SettingsProvider("MyCustomSettingsProvider.CustomSettingsProvider", "MyCustomSettingsProvider")]

    and also working if I had given it as


    Thanks for your help. Now I want to use SQL Server 2005 Express to store my settings using the custom SettingsProvider. Can you give me some suggestions how to do that…



  8. Here’s a scenario I can’t figure out how to address. I have a service that is currently using the new .NET 2.0 settings. These settings have application scope. What I want to be able to do is to change them during the installation phase of the service. I’m not having any luck figuring out how to go about doing this though. Can a service even call Save() on the settings? Where would that persist to?

    I can set the value of an application scoped setting by doing:

    Properties.Settings.Default["SettingName"] = "Blah"

    Upon calling Properties.Settings.Default.Save() though, the value disappears. Any suggestions?

  9. rprabhu says:

    Application scoped settings are read-only and cannot be saved at runtime. See the FAQ linked above for more details.

  10. Blair Leduc says:

    Can the path returned by Application.LocalUserAppDataPath and the path used by LocalFileSettingsProvider be the same? I need to store additional files, and it would make supporting the application alot easier if they could reside in the same directory (<AppPath>My Company<exe> versus <AppPath>My_Company<exe>_<signatures>).

  11. rprabhu says:

    Blair: Unfortunately not. As I have explained in the FAQ linked above, the user.config file path needs to meet certain isolation and robustness requirements that are not met by Application.LocalUserAppDataPath. The latter cannot be changed due to compatibility reasons.

    However, if your app is Clickonce deployed, both will be redirected to the Clickonce data directory and the only difference will be that the config file path will have a version dir.

  12. Blair Leduc says:

    Could there be a way to get the path that the LocalFileSettingsProvider uses? For example, Properties.Settings.ApplicationPath and Properties.Settings.UserPath?

    It really doesn’t matter to me what the directory is. It just would be nice to put everything in same place.

  13. rprabhu says:

    Here is how you can get the config file path.

    First get the Configuration object for the desired level:

    Configuration c = ConfigurationManager.OpenExeConfiguration(ConfigurationUserLevel.PerUserRoamingAndLocal);

    Now you can access the FilePath property off the Configuration object.

    Note that you need to add a reference to System.Configuration.dll.

  14. Blair Leduc says:

    Hey, that’s great! You should put that into your FAQ.

  15. rprabhu says:

    Good idea – added it to the FAQ.

  16. MDeevi says:

    I created a custom Settings Provider and now I do not want to use the app.config file for the settings. Does it arises any issues if I am not going to use app.config file? Does app.config take priority over the settings class for assigning defaults?

    Is there any mechanism in Visual Studio 2005 that we can tell the settings designer to generate the class but not the app.config values?

    Please let me know about these details….

  17. rprabhu says:

    If you aren’t using the default provider, then the app.config file plays no part and is not required.

    I don’t know a way to tell the settings designer to not put values in it. However, you could probably just get rid of the app.config before deploying the app.

  18. MDeevi says:

    Thanks Prabhu for your reply. We are planning a large application with many components (dlls). We realize that we can use different settings classes (groups) to separate functionality among the various components.

    To accommodate our settings groups, we are considering a hierarchical approach whereby MainSettings would hold some settings and also hold references to other settings classes/groups, which in turn could hold references to other settings classes/groups. For instance, you might access a setting via MainSettings.Component1Settings.SubcomponentASettings.TheSetting. however there is only one app.config file for the entire application! How do most projects handle settings for components? Does the main app handle reading/saving settings for all the components?Can we encounter any potential problems with this approach? Does the internal class generated by Settings Desginer prevent these type of references from going across dll boundaries?

    Please let me know about these details….

  19. rprabhu says:

    The user config files are per app domain, so it doesn’t matter which assembly accesses them, provided it is in the same app domain. So as long as the settings classes have unique full names, you don’t have to worry about it.

    Another approach you might find useful here is IPersistComponentSettings. See the docs for more information about this. You will find some info in the comments section of the FAQ as well.

  20. MDeevi says:

    How do we access the GroupName information from GetPropertyValues and SetPropertyValues in the custom SettingsProvider?

  21. rprabhu says:

    You can access it off the SettingsContext: context["GroupName"].

  22. MDeevi says:

    Hi Prabhu,

    We have implemented a simple SqlCustomSettingsProvider based on the Registry example provided in MSDN Samples.

    We have many settings and want to group them. In fact, we want to group them hierarchically, but that is outside the scope of the group name issue.

    We noticed that using multiple settings classes is a logical way to group settings. However, we would like to use a single settings provider for all settings classes. The settings architecture documentation (ApplicationSettingsBase class) states that "each class defines a settings group" and that "if the group name is not explicitly set by decorating the wrapper class with a SettingsGroupNameAttribute, then a name is automatically generated".

    Our design requires us to store the groupname in the settings database. This allows 2 different settings groups to each have a setting with the same name.

    How do we access the GroupName information from GetPropertyValues and SetPropertyValues in the custom SettingsProvider?

    Please kindly provide us some solution so that we can continue the rest of the things…..

  23. rprabhu says:

    My comment above has the answer (repeating here):

    You can access it off the SettingsContext: context["GroupName"].

  24. MDeevi says:

    Thanks Prabhu, We will look into the solution provided by you. If we face any problem we will get back to you.

    Thanks in advance….

  25. TheMask says:

    I have a big issue with client settings I would appreciate if you could comment on. When using strong names, the expected behavior of ApplicationSettingsBase.Upgrade() is thrown out the window if your version changes because an entirely new directory is created one level above the directory where side-by-side versions are contained, which apparently is the only place the default implementation of Upgrade() looks… Was this considered during the design and is it intentional? What is the recommended work-around? I am considering writing my own provider, because my assembly must be strong-named and I absolutely require upgrading settings with each release.

  26. rprabhu says:

    TheMask: Yes, this was a bug in Beta 2 and has been fixed recently. You should see the fix in the RC and final releases of .NET 2.0.

  27. TheMask says:

    Unless I’m missin’ something, it didn’t make it into RC1, did it? I recently tested it and the problem was still there unfortunately. Guess I have to wait until release…

    By the way, thanks for the quick response!

  28. rprabhu says:

    You are right – I just checked and found that the fix missed the RC release by 3 days. Sorry for the confusion.

  29. John Griffin says:

    I would like to have settings which are scoped which can be written by one user and and read by all users.

    The UserScopedSettingsGroup doesn’t work because the same user.config isn’t read equally by all users. The ApplicationScopedSettingsGroup doesn’t work because it is read only.

    I realize I can create my own SettingsProvider but then I seem to lose the .config file location, grouping, heirarchy, and general structure provided by the LocalFileSettingsProvide.

    Do you have any recommendations?


    P.S. I also can’t find the samples you mention in the faq on the Visual Studio RC1.

    i.e. / .Net Framework SDK / Samples and QuickStarts / Samples / Technology Samples / Windows Forms Controls Samples

  30. rprabhu says:

    John: This scenario is not supported by the built in provider, so unfortunately, I would have to recommend building your own. However, this is a fairly simple task once you figure out where and how you want to store the settings. Stuff like serialization is taken care of for you by the settings API.

    Here is the online link to the SettingsProvider samples:,VS.80).aspx

    Check out ‘Client Settings Web Services Sample’ and ‘RegistrySettingsProvider Sample’.

  31. Scott Searle says:

    We have an application that dynamically loads DLLs using reflection. This is essentially a plug-in architecture – it looks for DLLs in a particular directory that implement a particular interface and loads them.

    The question is this: Some DLLs need to have their own configuration data. With Visual Studio 2005, we’re allowed to create the settings information for the DLL project, and all of the constituent files are created (app.config, settings.*). However, when the DLLs try to access data using Properties.Settings.Default, the settings are not loaded from dllname.dll.config. How can we cause each DLL’s .config file to be loaded (and the Settings.Designer.cs properties to be loaded as a result)?

  32. rprabhu says:

    Config files are supported only for applications (exe), not libraries (dll). As such, dlls need to store their config in the host app’s config files. This should happen automatically for you – any settings you write at runtime will get written to the host application’s config files. As for default settings, you can either put them in the exe.config of your application, or simply supply them in code by specifying a DefaultSettingValueAttribute (which VS 2005 will do by default).

  33. says:


    We have a case where the dll is a Word Add-In and for securtiy reasons some of our customers will not allow any changes to winword.exe.config. They also will not allow any files to be placed in the Office subdirectories.

    So we need to place config information with our dll (which is in a different directory). How can we set things so our dll can read from autotag.dll.config?

    Again, this is a security limitation from some of our customers, we cannot use winword.exe.config.

    thanks – dave

  34. rprabhu says:

    The configuration system does not support config files for dlls, only exes. So to do something like this, you will need to implement a custom SettingsProvider. You can find samples/doc on how to do this on MSDN – it should be fairly easy.

  35. TheXRay says:

    I know that ConfigurationManager.GetSection uses the cached instance of objects inside the ConfigurationManager. I have two questions:

    1. Do the following two ways to access settings:

    string str = Settings.Default.testSetting;


    Settings set = Settings.Default;

    string str = set.testSetting;

    also use cached instances and what’s the difference between them?

    2. If I call a class that is inside my configuration class library that calls ConfigurationManager and returns ConfigurationSection instance to my application will there be caching for subsequent class calls in my application?

  36. Muleskinner says:

    Hi blog

    I am trying to make an extension to my.settings as I want to save the application password encrypted.

    I am trying to acomplish this by making a partial class:

    Namespace My

     Partial Friend NotInheritable Class MySettings

       Inherits Global.System.Configuration.ApplicationSettingsBase

           Private Function EncryptString(ByVal strPlain As String) As String


           End Function

           Private Function DecryptString(ByVal strCrypt As String) As String


           End Function

           <Global.System.Configuration.UserScopedSettingAttribute(), _

            Global.System.Diagnostics.DebuggerNonUserCodeAttribute(), _

            Global.System.Configuration.DefaultSettingValueAttribute("")> _

           Public Property frmLoginPassword() As String


                   Return Me.DecryptString(CType(Me("frmLoginPassword"), String))

               End Get

               Set(ByVal value As String)

                   Me("frmLoginPassword") = Me.EncryptString(value)

               End Set

           End Property

     End Class

    End Namespace

    This seems to be working, but every time I modify the Project Application Settings, the frmLoginPassword property is re-created in the original class hence giving a:

    ‘Public Property frmLoginPassword() As String’ has multiple definitions with identical signatures.

    Am I misusing the whole settings concept or is there a workaround?


  37. rprabhu says:


    1. Yes, they use cached values (both are equivalent). If you wish to force a refresh, you can call Reload().

    2. The config system does cache values, but you can call ConfigurationManager.RefreshSection() to force a read from the config file.


    Yes, modifying designer generated code is not recommended, since it can get overwritten. Instead, you can either wrap this property in your own one or do the encryption/decryption by subscribing to one of the events in ApplicationSettingsBase.

    This is an unfortunate limitation of dealing with designer generated code!

  38. > The configuration system does not support config files for dlls, only exes.

    Will they address this in the future. I think security restrictions will make this more common – especially for Add-Ins.

    thanks – dave

  39. rprabhu says:

    David: I don’t know the answer to that, since I work in a different group now. You could request it through MSDN Product Feedback or maybe contact Brad Abrams through his blog (, since I think his team owns this now.

  40. Derek says:

    I must admit even after reading the above, I’m still having trouble getting our data layer dll to use the main exe’s configuration file for a connection string.

    The exe has a config file and an application setting for connection strings.

    The dll has an application setting for connections strings.  I have tried labelling this the same and different from the the main executable.

    I then alter the config file (the executables) in the test environment, and the application continues to fall over.  It is easily fixed by hardcoding a valid connection string in the dll’s settings, but this isn’t configurable.


  41. rprabhu says:

    The name of a setting in the config file will be a concatination of the full class name and property name, something like MyApp.MySettings.ConnStringSetting. Since the namespace and class name of the dll’s settings class are different from that of the main exe, you might be seeing a mismatch.

    Try using the SettingsGroupNameAttribute – it is designed to help in such scenarios. Look it up in MSDN for more info.

  42. AndrewCr says:

    I’m having trouble loading a custom SettingsProvider from a COM object written in .net.  This same provider works with no problem in a WinForms App.

    I’m explicitly declaring the provider’s type in the SettingsProvider attribute.  My settings class is declared like so:

    <SettingsProvider(GetType(DBSettingsProvider))> _

    Public Class SomeSettings

       Inherits ApplicationSettingsBase

           Public Sub New()

               MyBase.New() ‘<– Breakpoint here

           End Sub


    When I instantiate the SomeSettings class and set a breakpoint where indicated, the properties are undefined before calling the parent’s constructor, but after stepping over the call they contain this message:

    Could not load type ‘Configuration2.DBSettingsProvider’ from assembly ‘DBSettingsProvider, Version=, Culture=neutral, PublicKeyToken=null’.

    Initially I thought it might be because the application was running a different directory than the COM object’s location, but I’ve tried copying the SettingsProvider’s assembly there with no luck.  I’ve also tried hooking the AppDomain.CurrentDomain’s AssemblyLoad event, but it never gets called.  What’s the best way to track down where/how the CLR is trying to load the provider?  Is there a way to pre-load it or set an explicit path to find it?



  43. rprabhu says:

    I recommend using fuslogvw (a tool that ships with the .NET SDK) to track down assembly load problems. Just start it up and set it to catch assembly load issues. Then run through your scenario. You should see an entry in fuslogvw corresponding to your load failure – it should have details on why the load failed.

  44. AndrewCr says:

    Sorry for the delay — I was busy on another project briefly, and then this took a while to figure out.  The problem seems to be: while "normal" assemblies referenced by the COM object are loaded in the LoadFrom context, the SettingsProvider was loading (or failing to load) in the Default context.  The upshot of this was (as I suspected) it was probing the calling App’s directory, not the COM object’s.  The Fusion Log viewer helped confirm that — it’s a good tool that I was unaware of.  Thanks very much for the pointer.

    The fix was to load the assembly in the AppDomain’s AssemblyResolve event.:

    [VB] Return GetType(DBSettingsProvider).Assembly


    [C#] Return typeof(DBSettingsProvider).Assembly

    Why, (you may ask) did my experiment of just moving the provider assembly to the calling app’s directory not work?  I had an unrelated bug:  When initializing the provider, I was accessing Assembly.GetEntryAssembly().GetName().Name, but in the COM object, GetEntryAssembly() is Null/Nothing.

    So, thanks for the tip — I could have gone around in circles for a long time looking at that.

  45. rprabhu says:

    No problem – glad to know you were able to resolve the issue!

  46. AndrewCr says:

     Thanks again for the help.  While I’m picking your brain…

     I can’t seem to find any way to set values in the Config parameter that gets passed to the SettingsProvider’s Initialize method.  Are there attributes I’m missing, or some other method of adding Name/Value pairs to Config?

  47. rprabhu says:

    The config parameter is of type NameValueCollection (

    You should just be able to use the Add method?

  48. AndrewCr says:

    Yes, I’m familiar with the NameValueCollection type.

    The problem is that the Initialize method is called from somewhere within the CLR, so I don’t have direct access to the collection.  I can’t figure out how to let the CLR know what I want to put in that NameValueCollection  parameter when it calls Initialize on my SettingsProvider.

  49. rprabhu says:

    Ah, okay. Let me preface this reply by saying that its been ~6 months since I moved to a different team in Microsoft, so I am not as familiar with this stuff as I was before.

    IIRC, in the client app case (i.e., when your provider is used through ApplicationSettingsBase), the parameters to Initialize will both be always null, and don’t mean anything.

    In the ASP.NET case, I think each provider is associated with a section in config that declares the provider. The config parameter passed to Initialize contains the values specified in this section.

    Make sense?

  50. AndrewCr says:

    Got it.  So in the Windows Forms case, I’ll need to get my initialization information from other (persistent) sources.  The application/consumer of the settings can’t pass me anything.

    That’s not great news, but better to know than to wonder.  Thanks for the Info.

  51. dougzhoez says:

    I know you’ve stated before if you want to change where the user.config file is saved you have to write your own settings provider, but I like everything about LocalFileSettingsProvider except the "Evidence" stuff that it appends to the application name in the path to user.config. Is there anyway to extend LocalFileSettingsProvider and just override this on piece?

  52. rprabhu says:

    Doug: Unfortunately, no, there isn’t a way to override the user.config path through the LocalFileSettingsProvider, since the path is constructed by the config system when the app domain loads. The LFSP doesn’t itself control the path construction.

    Just curious though: why do you wish to override the Evidence part of the path?

  53. dougzhoez says:

    I need to know exactly where the user.config file is going. Standard convension would be the exact path used by LocalFileSettingsProvider except that ApplicationName_Evidence… should just be ApplicationName. I guess the evidence part would be ok if it is constant. What causes the Evidence Hash and the other part to change? Will this always be the same for my application or would changing the assemblies loaded, for example, change it? I guess my question now is what determines what is appended to the application name, and what factors would cause it to change?

  54. rprabhu says:

    The Evidence portion is appended to your path to prevent collision with other applications that might happen to have the same name (unlikely that both company name and app name will match, but not impossible – also, a security risk). Specifically, the isolation is provided at the app domain level.

    The evidence is pulled from the ‘Evidence’ object associated with the app domain. If your app is signed, then the evidence depends only on the key you use – if the signature changes, so will the evidence, otherwise no. If not signed, then the evidence is based on the path to your application.

    So basically, changing the assemblies loaded do not affect the evidence portion of your user.config path.

  55. dougzhoez says:

    Thank you very much for answering my questions. Just to make sure I have things straight, so if we decide to obtain a certificate and sign our coding using signtool.exe, then the Evidence hash would be dependant on the public key? So as long as our public key stays the same, so will our Evidence hash? The signature changing due to the code changing will have no effect on the hash? Am I understanding correctly?

  56. rprabhu says:

    Yes, IIRC, that’s correct. Please confirm experimentally though, since, as I have mentioned before, it’s been nearly a year since I worked on this stuff, so don’t take my word for it!

  57. dougzhoez says:

    This does not seem to be the case. From my tests with signing the executable using signtool.exe, the only thing that I can tell that affects the Evidence hash is the executable location. Having it signed or not signed has no effect. I really need to folder name not to change on me; do you have any other ideas to get the Evidence hash to be a fixed value?

  58. rprabhu says:

    Hmm, that should work. Try a simple example with a fresh small application in VS 2005 and see if it works for you.

    Also, try running without the VS 2005 debugger attached – the debugger’s hosting process can cause the signature evidence not to be picked up by the config system. If this is the case, you can disable the hosting process (it is one of the debugger options).

  59. dougzhoez says:

    Form that test the Evidence hash is still only based off the application location if the assembly is signed with a certificate. However, if I use strong names it seems to work as you stated. Is this a bug? We really don’t want to use strong names but are fine with signing with a certificate. Is there something in the certificate signing process that I can do differently to make this work? Right now I just generated a .pfx file and added a post-build event that runs signtool.exe on my executable.

  60. rprabhu says:

    Ah yes, the app should be strong named – it is the strong name evidence that will be used to isolate your app’s user.config path. AFAIK, you cannot get this to work without strong naming.

    What’s your concern with strong naming?

  61. dougzhoez says:

    We don’t like strong naming because it forces all code called to be strong named, we have concerns about versioning, and the main complaint, it dramatically slows down developers with all the verification that it requires when you build. I guess we’ll have to live with the application’s location determining the hash. Thanks for all your help.

  62. dougzhoez says:

    Hi, I’m back. I’m trying to write a custom SettingsProvider and from looking at the examples (which aren’t very complete by the way since they don’t implement IApplicationSettingsProvider) when getting a value from storage, they are only setting the SettingsPropertyValue’s SerializedValue and not the PropertyValue. When I do this, the SerializedValue is correct but the property is always returning the default value. Could you explain the interactions between the PropertyValue and SerializedValue and how they are used to determine the value of the property?


  63. rprabhu says:

    IIRC, if you set the SerializedValue and query the PropertyValue, it will automatically deserialize it. If there is an error while deserializing, it will return the default value automatically.

    If you want to change this behavior to instead return exceptions when the deserialization fails, you could set the ThrowOnErrorDeserializing property on the SettingsProperty object to true.

  64. Rob Wade says:


    I’m late to this chat (which has been really helpful) so I hope you’re still there…

    I’ve created a custom ServiceProvider that reads/writes settings to a specific location used by a DLL.  This is working a charm when the DLL is initialised by a .Net application thread.

    The problem is that the DLL is also loaded in a COM thread.  In this case, the attribute [SettingsProvider(typeof(Csaaw.CsaawLogic.CsaawSettingsProvider))] is seemingly ignored (the SettingsProvider’s constructor is not called).

    Also, if I interogate the Providers property of my Settings class (to get its Count) I receive the following exception:

    Failed to load provider type: Csaaw.CsaawLogic.CsaawSettingsProvider, CsaawLogic, Version=, Culture=neutral, PublicKeyToken=null.

    I’ve been unable to figure out why my custom ServiceProvider would behave differently under COM whereas the LocalFileServiceProvider works fine.

    Any thoughts?

  65. Rob Wade says:

    I’ve resolved the issue.  In case anyone else encounters a similar problem, the resolution was to install my DLL in the Global Assembly Cache (GAC).

    The problem was that when my COM application was using the DLL, the Deserialize(…) method would be looking for the DLL in the COM application’s Path.

    Adding my DLL to the GAC made it visible to the Deserialize(…) method.

  66. rprabhu says:

    Rob: I was just composing a reply to your comment, when I saw that you resolved the problem. Cool 🙂

    Note that in general you can use the tool called fuslogvw (available in the SDK) to debug assembly/type load failures of this kind.

  67. Rob Wade says:

    Thanks for the tip and for hosting the discussion.  Without it I would’ve been pretty stuck!


Skip to main content