none
c# application settings - where are they stored?

    Question

  • hey, I have an application that saves it's settings in the "settings" tab of the program properties page in VS2005.  

    My question is... where does this actually get persisted to?  I thought it was the application.config file, but when I check this file it always contains the default values... not the persisted ones.

    I poked around in the registry and googled for this, but I can't figure out where it's saving this to...

    my reason for asking, is that I have an application that I frequently recompile and push code updates to.  everytime I recompile it, it loses it's saved settings... and I have to reinput them through the application.

    I would like to be able to export or save the file/registry section where this is stored, recompile my app, and then reimport the settings.   This application has a list of rules/filters that is fairly long and tedious to reenter, so it's becoming quite a pain to reinput...

    any ideas?  like I said, the persistance feature works great... just want to know _where_ it's actually persisting to.




    Friday, March 07, 2008 3:48 PM

Answers

  • The exact path of the user.config files looks something like this:

    <Profile Directory>\<Company Name>\<App Name>_<Evidence Type>_<Evidence Hash>\<Version>\user.config

    where

    <Profile Directory> - is either the roaming profile directory or the local one. Settings are stored by default in the local user.config file. To store a setting in the roaming user.config file, you need to mark the setting with the SettingsManageabilityAttribute with SettingsManageability set to Roaming.


    <Company Name> - is typically the string specified by the AssemblyCompanyAttribute (with the caveat that the string is escaped and truncated as necessary, and if not specified on the assembly, we have a fallback procedure).


    <App Name> - is typically the string specified by the AssemblyProductAttribute (same caveats as for company name).


    <Evidence Type> and <Evidence Hash> - information derived from the app domain evidence to provide proper app domain and assembly isolation.


    <Version> - typically the version specified in the AssemblyVersionAttribute. This is required to isolate different versions of the app deployed side by side.


    The file name is always simply 'user.config'.

    If you want to get to the path programmatically, you can do it using the Configuration Management API (you need to add a reference to System.Configuration.dll). For example, here is how you can get the local user.config file path:

       Configuration config = ConfigurationManager.OpenExeConfiguration(ConfigurationUserLevel.PerUserRoamingAndLocal);
       Console.WriteLine("Local user config path: {0}", config.FilePath);

    Friday, March 07, 2008 4:17 PM

All replies

  • See the Settings Files Location section of http://msdn2.microsoft.com/en-us/library/8eyb2ct1.aspx

    Friday, March 07, 2008 4:16 PM
    Moderator
  • I think following article will help:

     

    http://msdn2.microsoft.com/en-us/library/k4s6c3a0.aspx

     

    Friday, March 07, 2008 4:16 PM
  • The exact path of the user.config files looks something like this:

    <Profile Directory>\<Company Name>\<App Name>_<Evidence Type>_<Evidence Hash>\<Version>\user.config

    where

    <Profile Directory> - is either the roaming profile directory or the local one. Settings are stored by default in the local user.config file. To store a setting in the roaming user.config file, you need to mark the setting with the SettingsManageabilityAttribute with SettingsManageability set to Roaming.


    <Company Name> - is typically the string specified by the AssemblyCompanyAttribute (with the caveat that the string is escaped and truncated as necessary, and if not specified on the assembly, we have a fallback procedure).


    <App Name> - is typically the string specified by the AssemblyProductAttribute (same caveats as for company name).


    <Evidence Type> and <Evidence Hash> - information derived from the app domain evidence to provide proper app domain and assembly isolation.


    <Version> - typically the version specified in the AssemblyVersionAttribute. This is required to isolate different versions of the app deployed side by side.


    The file name is always simply 'user.config'.

    If you want to get to the path programmatically, you can do it using the Configuration Management API (you need to add a reference to System.Configuration.dll). For example, here is how you can get the local user.config file path:

       Configuration config = ConfigurationManager.OpenExeConfiguration(ConfigurationUserLevel.PerUserRoamingAndLocal);
       Console.WriteLine("Local user config path: {0}", config.FilePath);

    Friday, March 07, 2008 4:17 PM

  • thanks!  the path reference was the most helpful... I had already tried searching 'documents and settings' folder for user.config, but it came up blank which was adding to the whole confusion.

    I was searching for 'user.config' where user was the username of the person currently logged in.  This was incorrect, it's literally just 'user.config' not 'firstname.lastname.config' or having anything to do with your windows login (since it's stored in the profile directory I guess they avoid the redudancy of using the username twice).

    So now I know where the configs are.  I noticed it had a seperate directory for every single build of my application, which was strage because none of my other visual studio apps were like this.

    So I checked assemblyinfo.cs, and found this:

    // The assembly version has following format :
    //
    // Major.Minor.Build.Revision
    //
    // You can specify all the values or you can use the default the Revision and
    // Build Numbers by using the '*' as shown below:
    [assembly: AssemblyVersion("1.0.*")]

    Whereas all of my other applications had a hard-coded version like:

    [assembly: AssemblyVersion("1.0.0.0")]

    which explains why settings were resetting on every compile.  Not sure why this project was the only one created with this setting, bc I didn't manually mess with this.  VS inconsistencies I guess (sometimes I notice that AssemblyInfo.cs doesn't always create to the same place, sometimes it goes in the project folder, sometimes it goes into Properties subfolder).

    Anyways, this solves all my problems... thanks for all your help!

    Friday, March 07, 2008 4:46 PM