Library tutorials & articles
Isolated Storage in .NET
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.
Related articles
Related discussion
-
handling special character in xslt's
by bussureddy82 (1 replies)
-
String was not recognized as a valid DateTime.
by buvanasubi (22 replies)
-
how to select item to datagrid from textbox
by chandradev1 (12 replies)
-
String size limit and array upperbound limit
by Akhtar Hussain (2 replies)
-
ASP.NET Patterns every developer should know
by AndyGrant2005 (2 replies)
Related podcasts
-
CodeCast Episode 4: State of .NET, IE8, ASP.NET MVC, and O'Reilly Media
CodeCast Episode 4: State of .NET, IE8, ASP.NET MVC, and O'Reilly MediaHosts Ken Levy and Markus Egger discuss the new State of .NET events, IE8, ASP.NET MVC, followed by an interview from PDC with two editors from O'Reilly Media. More on ASP.NET MVC can be found at http://asp.net/mvc. Interview...
Related jobs
-
Microsoft .Net Architect
in AMSTERDAM (€50K-€90K per annum) -
Applicatie ontwikkelaar binnen Defensie
in Amsterdam (£50K-£90K per annum) -
Business Analist (Openbaar) Vervoer
in Amsterdam (€50K-€90K per annum) -
Application Engineer (VB, .Net, Java) - Standplaats: Utrecht
in Amsterdam (€50K-€90K per annum)
Events coming up
-
Dec
6
Developing AJAX Web Applications with Castle Monorail
London, United Kingdom
Monorail is the model-view-controller engine of the Castle Project, bringing many of the best ideas of Ruby on Rails to the .NET world. In this talk, David De Florinier and Gojko Adzic show how Monorail makes it easy to develop .NET based AJAX applications, and how to use the Castle Project to build Web 2.0 applications effectively. Come to this session if you are a .NET web developer. Everyone is welcome!
NiceIntro into another viable storage solution.
Thanks
This thread is for discussions of Isolated Storage in .NET.