No, isolated storage does not mean renting a Pod and putting it out in the woods somewhere! Rather it is the .Net framework's answer to a question that has long vexed developers: where to keep application configuration information.

This may sound like a simple problem, but it has been unexpectedly difficult to solve in a manner that addresses all the potential problems. Let's look at a little background.

Past Approaches

In the world of the Windows operating system, the first tool that Microsoft offered for storing application-specific configuration information was the INI file. These were plain text files that could be written and read with calls provided in most Microsoft APIs. INI files were easy to use and served many a developer well... until you bumped into their inherent limitations.

Without going into details, these were primarily the following:

• INI files had no way to represent hierarchical information.

• There was no standardized and safe place to keep INI files.

• INI files had a size limitation.

The next technique to come along for storing configuration information was the Windows registry, introduced along with 32 bit versions of the OS. The registry addressed the problems listed above for INI files, and added support for multiple users to boot. There's no doubt that the registry has been a success, but it, too, has problems:

• Because the registry is globally accessible, a carelessly written install routine or application can bollix up the registry data for other applications and render them unstable or unusable.

• The registry tends to swell to a huge size with duplicated and unneeded information, and a large registry slows down the entire system.

• It's difficult to find or edit information in the registry.

In the .Net framework, what about the application's CONFIG file? This file is always stored with the EXE file, so there is no "where" question. A config file is XML, with all the flexibility that implies, and it is application specific. The wrinkle — and it's a big one — is that these config files are intended for read-only information. In other words, they are created when the app is installed and remain unchanged unless the installation is updated. While you can write to the CONFIG file in most current versions of Windows, it is generally considered a bad idea to write to any folder under \Program Files — and that, of course, is where the CONFIG file is stored. What's more, Windows Server 2003 and future versions of Windows will not permit anyone without Administrator privileges to write to that location.