Everyday I’m learning new things about Visual Studio 2005 and version 2.0 of the .Net Framework. Most of the time when I “google” something (I like it when a company name becomes a word in the English language), I can quickly find several examples of what I want to do, and I quickly go about my business. However, now and then, there’s a topic for which I’m not able to find any really good examples. The new application settings feature in Visual Studio is, I believe, a case in point.

In the old days of Visual Studio 2003, there was a nice way to store application settings in a configuration file, so that the application could retrieve those settings at runtime. Someone, usually an administrator, could change the setting in the config file without the developer needing to recompile the application because the settings were contained in a separate file where they were stored as xml. As nice a feature as this was, the implementation in version 1.x of the Framework was someone limited. Mainly lacking was an API for writing settings to the file programmatically, and the settings were valid only for EXE’s and web apps, but not for individual DLL’s.

In Visual Studio 2005, the mechanism for application settings has been totally revamped. In VS 2003, there were “dynamic properties” for components, which could be set from the property sheet and were written to a config file. That has all been thrown out in VS 2005, replaced by a “Settings” property page for the project itself.

This means that config settings can apply not only to EXE’s and web apps, but also to individual DLL’s. VS 2005 provides a very nice editor for adding, changing and removing settings, and which allows you to designate a corresponding type (for example, int, string, Guid, DateTime, etc.). Visual Studio accomplished this feat by generating a settings class on the fly. The addition of strongly typed settings gives compile time type safety, which was lacking by default in VS 2003. Also, settings are scoped both at the Application level, and at the User level. So it’s possible to maintain settings that are specific to a particular user, such as the most recent position of the app’s main window, or other similar settings.

By the way, VS 2005 still generates an app.config file, which in turn is copied to a file with the same name as the assembly and placed in the same folder. The config file is a bit more sophisticated, with separate sections for application and user settings.

So what code do you write to retrieve these settings? That’s where my Google search came up a bit sparse. I did find one article, but it did not address separate app settings for DLL’s and the code snippet only showed how to enumerate settings, but not how to retrieve individual settings. So here’s how to do it:

// Get Project Settings
Properties. Settings settings = Properties.Settings.Default;

// Get App Settings
string strSetting = settings.StringSetting;
DateTime dateSetting = settings.DateSetting;
Guid guidSetting = settings.GuidSetting;
int intSetting = settings.IntSetting;

The Settings class in the Properties namespace is automatically generated by the Visual Studio IDE. Application scoped settings are read-only, while User scoped settings are read-write and are specific to the logged on user.

Click here for a sample application I created which demonstrates the new application settings feature of Visual Studio 2005, including settings used by a DLL.