Einstein:

Knowing how and where to store things is bread and butter stuff for an Application Developer. Applications need to store state information, options, user settings, configuration information, connection strings, their data, system information and much more. Choosing where to store this information is an art form as well as a science. And with issues like security and performance to contend with it’s important that you make the right choices.

You have several options as to how to store application related information, especially information that you want to persist between application usages: .ini files, Windows Registry, ,XML, and Isolated Storage.

The most recent type of storage involves an area of storage known as ‘Isolated Storage’—that was introduced to the Windows environment alongside the introduction of the .NET Framework.
_________

.INI FILES
_________

In a 16-bit Windows environment it was usual for application settings to be stored in .INI files. An .INI file (pronounced inny) is a plain text file format that can be read by any text editor. To access the .INI file programmatically usually meant you would use a Windows API call. Data storage is limited in these types of files because it is non-hierarchical and usually only contains plain text. .INI files were often stored in the Windows directory itself giving rise to other issues. .INI files were simple but the lack of structure and rules surrounding them led to the introduction of other mechanisms for storing applications settings.
_________

REGISTRY
_________

When we moved into the 32-bit Windows world for example, the registry largely replaced .INI files and it was seen as a step forward. It was a step towards a standard for storing application settings. The settings in the registry are globally accessible; they can be easily found and are stored in a hierarchical format. The Windows registry supports multiple users through hives (e.g. HKEY_CURRENT_USER), which was possible but unwieldy in a .INI file. But even the Registry has its share of issues to solve. It was prone to corruption because of the frequent access sometimes simultaneously by multiple programs. The registry is also a bit of a dumping ground and because of its growing size it is difficult to search and backup. The registry is a storage area that was overused
_________

XML
_________

When Microsoft was designing the requirements for the .NET environment, the engineers had the opportunity to standardise even further. They wanted to introduce a system that combined the best features of the Registry and INI files, without some of the limitations. In addition to being able to support separate application files and user files they needed to support any data storage format (e.g. binary, hierarchical, flat). Importantly, they also needed to protect application settings and data from other .NET applications (helping to avoid problems with registry corruption at the same time). Furthermore from a security stand point a restricted area was needed that would fit in with the .NET Framework’s model of Code Access Security. Isolated Storage is Microsoft’s first draft at meeting all of these needs.

For Visual Studio .NET developers, the .config file largely replacing the .INI file and Registry in the .NET environment at least in so much as it provides application wide settings. The .config file for an application will live in the same directory as the .exe file and will share the same name. At design time the file is called App.Config, as you build the solution the run time version is renamed with the same name as the .exe file. If your application is called MyApp.exe then your App.Config file will be renamed as MyApp.exe.config.

Your App.Config file has an XML format, and so is flexible and hierarchical. You’d store the kind of information here that you might store inside HKEY_LOCAL_MACHINE in the registry in as much as any user accessing that application in that directory shares the same configuration file. Developers often think that this is a good storage area for per-user information, but it’s not designed for that. And of course it’s read only storage and not really designed to store information that will change whilst your application is running (like state information).

The .NET Framework provides classes for working directly with Application Settings and in particular there is an AppSettingsReader class (but note the absence of a class to write settings). You can use this class to read from the appSettings section of the config file, containing name/value pairs.
_________

ISOLATED STORAGE
_________

When it comes to per-user information you can follow a couple of different paths. Either you can develop your own ad-hoc routines to store user settings and other information in various places or you can consider Isolated Storage.

Isolated storage is a special area on the hard drive that your application knows how to find. The clever thing is that your application can’t see the physical path location (this is managed by the .NET framework). What’s more your application doesn’t need permission to write to the hard drive – so this technique is suitable for .NET applications that are running in a restricted security mode. Only the User and Assembly that creates the storage can have access to it. If your corporate environment has been designed to support hot-desking then Isolated Storage also supports roaming profiles

In essence Isolated Storage is a well thought out viable storage area that you can take advantage of when you’re considering your storage options. Isolated Storage Classes live in the System.IO Namespace and consist of a Store (the storage area) which has methods to create directories and read files and you can read and write to the area using Streams.