email article printer friendly get the code more resources

Store Data Safely
Use isolated storage to protect application data and give your distributed rich-client apps I/O capability.
by Brian Noyes

Technology Toolbox: VB.NET, C#

Reading data from and writing data to file storage is one of software systems' most common requirements. However, a number of subtle problems can emerge when programming this requirement. First, the user must have permission to read from and write to the location the code is trying to access. Next, you must prevent one user's files from overwriting another user's, or even worse, from overwriting or corrupting system files. You also need to ensure that you keep data one application writes from overwriting another app's data.

Isolated storage—an easy-to-use, elegant solution built into the .NET Framework base class library and the runtime—addresses these problems. Isolated storage allows you to write file input/output (I/O) code that reads from and writes to a virtual file system the runtime manages. That virtual file system is isolated by user, and you can choose to isolate it further by assembly or application domain (AppDomain). The files are stored as part of a user's profile, so users can access their isolated storage files on any workstation they log on to if roaming profiles are configured on your LAN. By letting the .NET Framework and the runtime provide these levels of isolation, you can relinquish responsibility for maintaining separation between files, and you don't have to worry that programming oversights or misunderstandings will cause loss of critical data.

In this article, I'll describe in depth how isolated storage works, explain how to use it, and discuss some considerations regarding how and when to use it. I'll cover some basics of .NET file I/O quickly to lay the groundwork, then describe a simple sample application that demonstrates the use of isolated storage. I'll discuss briefly some additional samples that demonstrate options for configuring and using isolated storage. I'll also discuss how architectural choices can affect the levels of accessibility of data stored in isolated storage, and what you need to think about to deploy applications that use isolated storage. Finally, I'll give you a few scenarios where using isolated storage makes sense (and a few others where it doesn't).

You use a combination of streams, readers and writers, and file system objects to perform file I/O in .NET. The lowest level you usually need to think about is a stream—an abstract representation of an underlying storage or persistence mechanism. Through the process of reading data from or writing data to a stream, you end up serializing the data into a stream of bytes that get transferred to that persistence mechanism. The .NET Framework provides stream classes for files, memory, and network sockets. These classes are all derived from the Stream base class, and you can usually read from and write to a stream without having to know much about the underlying persistence mechanism. You can layer streams on top of one another to provide additional functionality in the serialization process; for example, you can layer a CryptoStream on top of a NetworkStream to encrypt the bytes transferred through a socket connection.