(Part 1 of 2) Anyone who worked with .NET 1.1 to build a client-based .NET application quickly discovered a significant limitation in how it provided support to save application or user defined data (often called "settings").' Basically, there was no way to do it without rolling your own storage mechanism.' You could, of course, rely on the Registry to store data as many pre-.NET applications do since it is relatively easy to access the Registry with the Registry class.' The Registry has the benefit of being accessible, simple, and it allows for structured/hierarchical data to be stored.' It has the downside of being difficult to edit by the typical end-user even with tools such as RegEdit, and is very easy to corrupt if care is not take during editing.' It was a big step up from not having anything, but when .NET was rolled out, application-based settings were moved to a defined storage file called a "config" file attached to the executable.'
In .NET 1.1, a .config file is an XML based file containing a configuration section and an appSettings child section.' Each application setting is added to the appSettings section via an add verb as follows:
<?xml version="1.0"
encoding="utf-8" ?>
<configuration>
<appSettings>
<add key="LastPath"value="C:\Program Files\MyCo\MyApp" />
<add key="RegPath"value="Software\MyCo\MyApp" />
</appSettings>
</configuration>
In this example, you can see that I've added two settings named LastPath and RegPath.' These are assumed to be application (not user) level settings and are read-only.' They're great for making applications more flexible, since common values that affect how an application runs can be specified in the file in an easy-to-read and edit format.' An installation program is a great vehicle for making these kinds of modifications for an application " as the installer runs, it can update (or generate) the configuration file using environmental or other dynamic data as appropriate.'
But this approach presented two serious problems that we'll look at in this series " the data was read-only, which prevented application (or user specified) updates at run time, and there was no way to have a set of application-level, and user-level settings.' Application-level is defined to be those items that all users of an application share even if they are changed while user-level is defined to be items that have values specific to the user account the application is executed under.' Particularly for those developers who are seeking to have their applications become compliant with the latest compliance directives from Microsoft for client-based applications, these issues pose a serious dilemma " how to become compliant using the built-in, but flawed mechanism for storing settings.
The typical solution was to roll a custom persistence mechanism for settings that in a .NET application usually meant writing out the data as an XML file.' Although this works if done properly and with great care, it has its own issues such as:
- What happens if new items or different items need to be stored in the future?
- Where should user-level settings be stored?
- How can defaults for missing items be specified at runtime?
- How should non-textual data be serialized to the XML file?
- What if some other format than XML is desired in the future?
This issue came up so often during .NET 1.1 development that the Microsoft Patterns and Practices group developed the Configuration Application Block (a reusable library of free code) that attempted to provide a uniform way of dealing with application and user-level settings in a .NET 1.1 application.' This block formed the basis of the approach used in .NET 2.0, and we'll delve into it in the next article in this series.
Saving Settings in .NET 2.0 Apps, Part 2
.NET Cast
Whether you are moving to .NET from Win32 or have been using .NET since 1.0, I encourage you to listen to Dr. Dobb's .NET Cast, an Internet radio show that I host..' Hear from the people behind .NET and key experts in the industry on getting the most from the .NET framework.' If you have more questions on your own migration efforts in .NET, you can contact me here.
