Members

Technology Zones

IBM Learning Center

Articles

Hosted By

MaximumASP

Info

Rated
Read 30,522 times

Contents

Related Categories

Isolated Storage in .NET - Overview

grahamp

Overview

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 we make the right choices.

This article examines an area of storage known as ‘Isolated Storage’ that was introduced to the Windows environment alongside the introduction of the .NET Framework. We’ll discover, what it is and how and why to use it.

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.

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.

Graham Parker is a co-founder and principal of DevTrain and spends his time consulting, developing and training. He is one of a handful of MVP's in Visual Basic around the world, and has been developing using Visual Basic since 1993. Graham was a founding member of VBUG in 1994, and held the role of Chairman of the group until March 2005. Graham is a frequent speaker at technical conferences and has presented on a number of different topics to diverse audiences including VBITS, VBUG, the Access User Group and the British Computer Society. In addition to working in the IT industry since 1985, Graham holds a BSc Honours degree in Applied Computer Systems from Brunel University.

Comments