Dec 6, 2008

Reasons to Avoid Visual Studio's Application Settings

The VS IDE has what, at first glance, appears to be a very convenient way to create and maintain both application and user settings for your application. Under the properties folder you can access the Settings.settings dialog and both create new properties and specify their type, scope and value in the convenient table editor shown below. What's not so clear or convenient is the difference in how properties of different scope are treated. The user properties (those you want to allow your users to change while using your application) start off life like the application settings in the AppName.exe.config file. However , once the user makes changes the settings are moved to a file named "user.config" that is stored in the deep dark recesses of your file system. The final rock you turn over will lead you to path similar to this: %APPDATA%\[CompanyName]\[AppName_guid]\[version]\user.config. You can find out where %APPDATA% is by going to a DOS prompt (just can't seem to get away from that thing can we) and typing C:> echo %APPDATA% or you can type C:\ set and scan through the resulting alphabetically ordered list. My location was something like c:\users\myUsername\Roaming. Actually it's a little more complicated than this because my system had several AppNamme_guid folders where the GUID was different and it was pretty well impossible to tell what the different folders were for. While I can see how this allows a user to have multiple versions of an application with different settings, and it allows multiple users on the same machine to have different settings, I seldom if ever would have this need. The HUGE downside is that during development, every new release wipes out the settings my users have made for testing purposes. This has not been making me very popular. Knowing that location of this hidden file and allowing them to copy and paste helps a little but still doesn't make them any too happy. I could not find any option that allowed me to control this rather byzantine behavior. [Turns out I just didn't look hard enough - See Bob's comment below on using Settings.Upgrade() and Settings.Reload() ]
The other problem with this default solution is it only supports a single large flat file model of preferences. Since VS provides visual tools for creating a strongly typed dataset, which can be mated to an .xml file, that seems like a much better way to store preferences. With the .xsd approach you can create a hierarchal relationship between data tables and create many to one relationships which makes storing preferences for multiple related objects much easier. It's a little more work to set up but in the long run pays more benefits. You can even leverage LINQ to query your settings. It is also fully supported by data binding. In fact, once you set it up you'll find yourself adding tables for drop down lists and other constant data, so that you can easily data bind to it. Plus you most likely won't write code that hides the .xml file requiring your user's to partake in a scavenger hunt if they want to preserve their settings between releases. You'll probably just store your preferences file right there in the same folder with your application data. Just think not only will it be easy to find, it will be easy to back up, move, replace and even change with a text editor.

3 comments:

Brad said...

I've noticed that happening as well, and creating your own settings access is a nice idea, especially if you make it reusable.

At my current job, I had to stay with the VS settings due to political reasons, and found the following solution workable: http://www.codeproject.com/KB/vb/CustomSettingsProvider.aspx?display=PrintAll - you can specify a custom provider, in this case it allows saving the settings to an XML file in a location you specify. This prevents the version from causing problems (unless you want it to).

Anonymous said...

If you check the ApplicationSettingsBase class you will note there is an Upgrade function. Just call this somewhere in your initialization for the settings: Properties.Settings.Default.Upgrade(). There are other handy functions in there too. I don't know why they didn't design it to upgrade automatically.

Bob said...

There is a way to avoid having to search for and copy/paste app settings files. I do this with all my VB apps and it works great especially during the initial months of deployment when we release a number of "fixes". Create an application setting called UpgradeSettings and set the default value to True. Then run this code every time your app starts:

My.Settings.UpgradeSettings = True Then
My.Settings.Upgrade()
My.Settings.Reload()
My.Settings.UpgradeSettings = False
End If

and make sure that "Save My.MySettings on Shutdown" is checked in the application properties

About Me

My photo
Tod Gentille (@todgentille) is now a Curriculum Director for Pluralsight. He's been programming professionally since well before you were born and was a software consultant for most of his career. He's also a father, husband, drummer, and windsurfer. He wants to be a guitar player but he just hasn't got the chops for it.