January 27, 2021
Hot Topics:

Building Persistence into .NET Programs

  • By Mike Gunderloy
  • Send Email »
  • More Articles »

The IsolatedStorageFile class is the .NET Framework's answer to the problem of where to store things on a user-by-user basis. Rather than force you to deal with the different available locations in different circumstances, the Framework takes care of all those messy details for you. When you instantiate an IsolatedStorageFile object, you get back an entire virtual file system that you can populate with directories and files. The user of the application is guaranteed to be able to read and write to this virtual file system. If they have a roaming profile, it will follow them around. In this particular bit of code, I've asked the .NET Framework to deliver an isolated store based on both user and assembly, so it won't conflict with stores assigned to any other user or application. After getting the store, I can create an IsolatedStorageFileStream object in it, which acts like any other Stream object.

The next step in the code is to create an instance of the Settings object and to populate it with the appropriate data from the application. Finally, I want to write the object out in a format that preserves its structure, and that can be reconsistituted to the original object. Once again, the .NET Framework comes through for me here. You're probably familiar with the Simple Object Access Protocol, SOAP, in the context of Web Services. SOAP specifies a way to encode objects into XML. That's exactly what I want to do here; fortunately, the Framework lets me call directly into the SOAP formatting engine by instantiating a SoapFormatter object and calling its Serialize method.

So, when this code runs, my Settings object will be packed up in a neat little XML file and stored somewhere that the user can get at it. What about the other end of the process?

Reconstituting the Settings Object

Because I want the persisted settings to be applied as soon as the form is loaded, I've placed the code in the Form's Load event handler:

private void Form1_Load(object sender, System.EventArgs e)
		// Get the isolated store for this assembly
		IsolatedStorageFile isf = 

		// Open the settings file
		IsolatedStorageFileStream isfs1 = 
			new IsolatedStorageFileStream("HTMLBuilderSettings.xml", 
			FileMode.Open, FileAccess.Read, isf);

		// Deserialize the XML to an object
		Settings s = new Settings();
		SoapFormatter SF= new SoapFormatter();
		s = (Settings) SF.Deserialize(isfs1);

		// And apply the settings to the form
		this.Top = s.Top;
		this.Left = s.Left;
		this.Height = s.Height;
		this.Width = s.Width;

	catch (Exception ex)
		// No file found. Use the form's default settings


A little inspection should convince you that the loading code is just the reverse of the saving code. Open the settings file, deserialize the XML to an object, and then pick apart the object's public fields to get at the persisted information. If anything goes wrong, the form will just open with its default settings (the size and contents that were saved in the designer when the application was compiled.

Code You Can Use

That's all there is to it! To use this code in your own applications, you just need to alter the Settings object so that it has public fields for each piece of information that you'd like to persist. Then read from those fields when the application starts, and write to them when it ends. Your users will thank you for the extra effort.

About the Author

Mike Gunderloy is the author of over 20 books and numerous articles on development topics, and the lead developer for Larkware. Check out his MCAD 70-305, MCAD 70-306, and MCAD 70-310 Training Guides from Que Publishing. When he's not writing code, Mike putters in the garden on his farm in eastern Washington state.

Page 2 of 2

This article was originally published on June 16, 2003

Enterprise Development Update

Don't miss an article. Subscribe to our newsletter below.

Thanks for your registration, follow us on our social networks to keep up-to-date