Client Configuration

In previous versions of Windows Forms, application developers could store application-specific configuration data within an application.exe.config file, deployed alongside the application executable. Settings like connection strings and URLs were commonly stored in this fashion.

Windows Forms 2.0 takes that functionality many steps forward by introducing a number of cool new features to the configuration system. The API for accessing settings has been made much more friendly thorugh the use of strong-typing: now, instead of everything being stored and visible in the API as a string, booleans become "bools", enums become enums, etc. There is support for almost any type you can throw at the sysem, including your own custom types.

Another feature is user-scoped settings. The perfect logical step beyond machine- and app-scoping that exists today, this feature allows full read/write settings stored, by default, in a new user.config file, which is itself stored in the proper Windows Logo-compliant locations within the filesystem. User-scoped read/write settings open up a whole new world of possibilities for applications, perfect for storing settings like user preferences and other types of Tools->Options-type information.

The entire feature is accessible via rich designtime support, including the ability to create new settings and modify existing setting defaults. Add to this the ability to bind settings to component properties with simple designtime gestures, and you have an amazing amount of fuctionality available without writing a single line of code!

And if that's not enough, the new settings features are built on a pluggable provider model. Don't like the .config file system and semantics that exist today? Roll your own provider and replace! Great examples of the possibilities here include a Web Service-based provider that could store settings on a central server—a perfect complement for your ClickOnce-deployed applications.