9.18 Use an Isolated Store

Problem

You need to store data in a file, but your application doesn't have the required FileIOPermission for the local hard drive.

Solution

Use the IsolatedStorageFile and IsolatedStorageFileStream classes from the System.IO.IsolatedStorage namespace. These classes allow your application to write data to a file in a user -specific directory without needing permission to access the local hard drive directly.

Discussion

The .NET Framework includes support for isolated storage, which allows you to read and write to a user-specific virtual file system that the common language runtime (CLR) manages . When you create isolated storage files, the data is automatically serialized to a unique location in the user profile path (typically a path like c:\documents and settings\[username]\local settings\application data\isolated storage\[guid_identifier]).

One reason you might use isolated storage is to give a partially trusted application limited ability to store data. (See recipe 13.1 for more information on partially trusted code.) For example, the default CLR security policy gives local code unrestricted FileIOPermission , which allows it to open or write to any file. Code that you run from a remote server on the local Intranet is automatically assigned less permissionit lacks the FileIOPermission , but it has the IsolatedStoragePermission , giving it the ability to use isolated stores. (The security policy also limits the maximum amount of space that can be used in an isolated store.) Another reason you might use an isolated store is to better secure data. For example, data in one user's isolated store will be restricted from another nonadministrative user.

The following example shows how you can access isolated storage:

 using System; using System.IO; using System.IO.IsolatedStorage; public class IsolatedStoreTest {     private static void Main() {         // Create the store for the current user.         IsolatedStorageFile store =              IsolatedStorageFile.GetUserStoreForAssembly();         // Create a folder in the root of the isolated store.         store.CreateDirectory("MyFolder");         // Create a file in the isolated store.         Stream fs = new IsolatedStorageFileStream(           "MyFile.txt", FileMode.Create, store);         StreamWriter w = new StreamWriter(fs);         // You can now write to the file as normal.         w.WriteLine("Test");         w.Flush();         fs.Close();         Console.WriteLine("Current size: " + store.CurrentSize.ToString());         Console.WriteLine("Scope: " + store.Scope.ToString());         Console.WriteLine("Contained files include:");         string [] files = store.GetFileNames("*.*");         foreach (string file in files) {             Console.WriteLine(file);         }         Console.ReadLine();     } } 

By default, each isolated store is segregated by user and assembly. That means that when the same user runs the same application, the application will access the data in the same isolated store. However, you can choose to segregate it further by application domain so that multiple instances of the same application receive different isolated stores, as shown here:

 // Access isolated storage for the current user and assembly // (which is equivalent to the first example). store = IsolatedStorageFile.GetStore(IsolatedStorageScope.User    IsolatedStorageScope.Assembly, null, null); // Access isolated storage for the current user, assembly,  // and application domain. In other words, this data is only // accessible by the current application instance. store = IsolatedStorageFile.GetStore(IsolatedStorageScope.User    IsolatedStorageScope.Assembly  IsolatedStorageScope.Domain,    null, null); 

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. (In this case, the store must be specifically designated as a roaming store by applying the IsolatedStorageFile.Roaming flag when it's created.) By letting the .NET Framework and the CLR 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.