My.Settings file location

My.Settings file location

• HanJin

  I'm beginning to get really annoyed with this settings system.
  Due to this limitation I have decided NOT to use the My.Settings at all, except for one Application scoped setting containing a connectionstring.

  I have de-selected the "Enable application framework" and therefore also the "Save My.Settings on shutdown" but it still creates folders and files in my app-data folder.

  In other projects, where I do use the application framework, I have also deselected the "Save My.Settings on shutdown" and even without any settings at all, files still get's created.
  I have even altered the template so I won't have to set this for each new project.

  I can't find a pattern for when these files are created, because they are not there after each run. But suddenly, without any logical reason (that I can find), they are there.

  The current provider is "as is" I guess. Nothing to do about that.

  So my question is now: When will MS supply us with a new provider with appropiate settings to control how and where settings are saved

  I know we can write our own, and i've tried, but that didn't stop the files from appearing in the app data folders.

  
  

• janislkovach

  I just got some feedback indicating my workplace just might go along with .Net's default handling of the location of user.config. That makes me happy because I didn't want to write a whole custom SettingsProvider.
  
  Anyways, I'm a little confused about enabling the "roaming" user.config file. How do I do this
  
  According to the FAQ at http://blogs.msdn.com/rprabhu/articles/433979.aspx
  
  "To store a setting in the roaming user.config file, you need to mark the setting with the SettingsManageabilityAttribute with SettingsManageability set to Roaming"
  
  I don't see any way to do this in the Visual Settings Designer. Are we supposed to do this manually If so, how
  
  Thanks for any information or help. :)
  
  
  
  

• radik

  The 'settings' are a nice handy short cut and way better than wha we used to have. However, if you don't like it, save the settings manually to the file name, format and location you want.

  I believe your problem may be in the click once distribution: it works some other magic behind the scenes. If you do an xcopy, and don't have 'save my settings' selected, it shouldn't create the file.

  
  
  

• defiance

  I'm in the same boat. I want to avoid writing a whole provider. Is it possible to create a provider that inherits from LocalFileSettingsProvider and just override a method that determines the location of the user.config file
  
  

• Dundappa Kamate

  Thanks so much! I can't believe I didn't see that earlier.
  
  

• K.S.RamakrishnaPrasanna

  MS Johan Stenberg wrote:

  Omron, what files are you referring to For settings, there is the (design time only) <settings file name>.settings file that contains (among other things) the name, type and default value for each settings, there is the <settings file name>.designer.vb that contains the class that is generated from the <settings file name>.settings. None of these files should be deployed & show up when you install your application. In addition to this, the settings designer will also create an app.config file (if there isn't one already in the project) and add the default values of your settings to it. The app.config file will be renamed to <app name>.exe.config file and is included when you install your app. At runtime, there may be two user.config files created when you save your settings, one for changed user-scoped settings, and one for changed roaming user-scoped settings. The auto-save settings on application shutdown only tells the generated settings class that it should automatically save changed values when you shut down your application, not that my.settings won't be used. The only way to turn off My.Settings and My.Resources is to remove the default resource and settings file from your project - they don't respect the "enable the application framework option". Regarding the control over anything/something issue; the way that you do have control over this is by using a different settings provider. We never expected to be able to cover all possible requirements for how settings should be persisted, which is why an extensible model where you can change the settings provider was selected. Best regards, Johan Stenberg

  Sorry for the delay. I've been away for a while.

  In my application data folder I suddenly have 4 folders with the same name as a sample program I made.
  This sample program had no settings at all, and the "Save..." option was unchecked.
  But still files containing virtually nothing are created.

  This is a quote from one:

  < xml version="1.0" encoding="utf-8" > <configuration> <configSections> </configSections> </configuration>

  I don't think they show up when the app is deployed and working, but the do show occasionally while debugging and it pains me, because, as I mentioned earlier, I do a lot of small samples and tests that never make it to deployment, so it's just a waste of diskspace, and it's a drag to check those folders regularly to clear them.

  Regarding the control issue, I fully respect the you can't design for every users whishes in mind, but to me, it seems that being able to choose were files go is a fundamental feature.

  I thought that one of the ideas with the .NET framework was, that everything an app needed was in the app folder. DLL's etc.
  Then it seems strange to me that settings get thrown into a folder some strange place on the harddrive, that the user can't even see without showing hidden files.
  I can see the usefulness of this with multiuser systems, but not everyone runs on a multiuser system.
  
  Also, I tried to make a provider myself, and I got it working pretty well, but the aforementioned files still popped up.
  Maybe it's the designer and part of the build process . I don't know.

  Maybe I'm alone on this, and it's just me being excentric, but I find it hard to believe that me and BlueBettle are the only ones with this issue.

  Just to recap: The architecture of the current provider is a minor thing. It's the fact that I can't stop these files from appearing that gets me.

  Cheers.

  
  

• Didier Frund

  If you select a setting in the settings designer and peek in the properties window (usually at the bottom right hand side, View->Properties window if not already visible), there should be a Roaming settings that you can set...

  Best regards,
  Johan Stenberg

  
  
  

• RITZ

  Omron, what files are you referring to For settings, there is the (design time only) <settings file name>.settings file that contains (among other things) the name, type and default value for each settings, there is the <settings file name>.designer.vb that contains the class that is generated from the <settings file name>.settings. None of these files should be deployed & show up when you install your application.

  In addition to this, the settings designer will also create an app.config file (if there isn't one already in the project) and add the default values of your settings to it. The app.config file will be renamed to <app name>.exe.config file and is included when you install your app.

  At runtime, there may be two user.config files created when you save your settings, one for changed user-scoped settings, and one for changed roaming user-scoped settings.

  The auto-save settings on application shutdown only tells the generated settings class that it should automatically save changed values when you shut down your application, not that my.settings won't be used. The only way to turn off My.Settings and My.Resources is to remove the default resource and settings file from your project - they don't respect the "enable the application framework option".

  Regarding the control over anything/something issue; the way that you do have control over this is by using a different settings provider. We never expected to be able to cover all possible requirements for how settings should be persisted, which is why an extensible model where you can change the settings provider was selected.

  Best regards,
  Johan Stenberg

  
  
  

• The OAP

  The LocalFileSettingsProvider do not expose a way to change the location of the user.config files. In order to get the behavior you want, you'd have to use another provider. The only change you need to make to the settings class is to tell it what provider to use...

  Raghavendra has some additional information here: http://blogs.msdn.com/rprabhu/articles/433979.aspx

  Luckily enough, it is not that difficult to write a settings provider - check out http://msdn2.microsoft.com/ms181001.aspx or http://msmvps.com/blogs/gbvb/archive/2004/10/04/14929.aspx for examples that you may find useful.

  Best regards,
  Johan Stenberg

  
  
  

• TheGriff

  I was afraid that

  But thanks anyway.

  
  

• OMCPero

  Saving manually is how I'm doing it at the moment.

  I agree that it's nice and handy and I would like to be able to use it. It just bugs me that I have absolutely no control over anything.

  
  

• Rob Bazinet

  I had some interesting observations about settings.

  Don't know if it applies to your situation.

  See:

  http://forums.microsoft.com/MSDN/ShowPost.aspx PostID=485886&SiteID=1

  
  
  

• xibalba7

  In Java, we can look at the source code for any Java class in their base library. Is the same thing true for .Net
  
  I want to write a custom SettingsProvider that works exactly like LocalFileSettingsProvider except I want to be able to specify a different location for the user.config file.
  
  
• My.Settings file location