This documentation is archived and is not being maintained.

Scenarios for Isolated Storage

Isolated storage is useful in many situations. Five of the most readily identifiable scenarios are described as follows:

  • Downloaded controls. Managed code controls downloaded from the Internet are not allowed to write to the hard drive through normal I/O classes, but they can use isolated storage to persist users' settings and application states.
  • Persistent Web application storage. Web applications are also prevented from using I/O classes. These programs can use isolated storage for the same purposes as downloaded components.
  • Shared component storage. Components that are shared between applications can use isolated storage to provide controlled access to data stores.
  • Server storage. Server applications can use isolated storage to provide individual stores for a large number of users making requests to the application. Because isolated storage is always segregated by user, the server must impersonate the user making the request. In this case, data is isolated based on the identity of the principal, which is the same identity the application uses to distinguish between its users.
  • Roaming. Applications can also use isolated storage with roaming user profiles. This allows a user's isolated stores to roam with the profile.

Although isolated storage is well suited to the scenarios described previously, there are a few cases in which you should not use isolated storage:

  • Isolated storage should not be used to store high-value secrets, such as unencrypted keys or passwords, because isolated storage is not protected from highly trusted code, from unmanaged code, or from trusted users of the computer.
  • Isolated storage should not be used to store code.
  • Isolated storage should not be used to store configuration and deployment settings, which administrators control. (User preferences are not considered to be configuration settings because administrators do not control them.)

Many of today's applications use a database to store and isolate data, in which case one or more rows in a database might represent storage for a specific user. You might choose to use isolated storage instead of a database when the number of users is small, when the overhead of using a database is significant, or when no database facility exists. Also, when the application requires storage that is more flexible and complex than what a row in a database provides, isolated storage can provide a viable alternative.

See Also

Isolated Storage | Performing Isolated Storage Tasks | Isolated Storage and Roaming