When an application stores data in a file, the file name and storage location must be carefully chosen to minimize the possibility that the storage location will be known to another application and, therefore, will be vulnerable to corruption. Without a standard system in place to manage these problems, developing ad hoc techniques that minimize storage conflicts can be complex and the results can be unreliable.

With isolated storage, data is always isolated by user and by assembly. Credentials such as the origin or the strong name of the assembly determine assembly identity. Data can also be isolated by application domain, using similar credentials.

When using isolated storage, applications save data to a unique data compartment that is associated with some aspect of the code's identity, such as its publisher or signature. The data compartment is an abstraction, not a specific storage location; it consists of one or more isolated storage files, called stores, which contain the actual directory locations where data is stored. For example, an application might have a data compartment associated with it, and a directory in the file system would implement the store that actually preserves the data for that application. The data saved in the store can be any kind of data, from user preference information to application state. For the developer, the location of the data compartment is transparent; stores usually reside on the client, but a server application could use isolated stores to store information by impersonating the user on whose behalf it is functioning. Isolated storage can also store information on a server with a user's roaming profile so that the information will travel with the roaming user.

Back to top

Using isolated storage enables partially trusted applications to store data in a manner that is controlled by the computer's security policy. This is especially useful for downloaded components that a user might want to run cautiously. Security policy rarely grants this kind of code permission to access the file system using standard I/O mechanisms. However, by default, code running from the local computer, a local network, or the Internet is granted the right to use isolated storage.

Administrators can limit how much isolated storage an application or a user has available, based on an appropriate trust level. In addition, administrators can remove a user's persisted data completely. To create or access isolated storage, code must be granted the appropriate IsolatedStorageFilePermission.

To access isolated storage, code must have all necessary native platform operating system rights. For example, on Windows 2000 the access control lists (ACLs) that control which users have the rights to use the file system must be satisfied. .NET Framework applications already have operating system rights to access isolated storage unless they perform (platform-specific) impersonation. In this case, the application is responsible for ensuring that the impersonated user identity has the proper operating system rights to access isolated storage. This access provides a convenient way for code that is run or downloaded from the Web to read and write to a storage area related to a particular user.

Back to top

Sometimes it is helpful to verify a change to isolated storage by using the file system of the operating system. Developers might also need to know the location of isolated storage files. This location is different depending on the operating system. The following table shows the root locations where isolated storage is created on a few common operating systems. Look for Microsoft\IsolatedStorage directories under this root location. You must change folder settings to show hidden files and folders in order to see isolated storage in the file system.

Back to top

Three main classes are provided to help you perform tasks that involve isolated storage:

• IsolatedStorageFile, which derives from IsolatedStorage, provides basic management of stored assembly and application files. An instance of the IsolatedStorageFile class represents a single store located in the file system.

• IsolatedStorageFileStream, which derives from System.IO..::.FileStream, provides access to the files in a store.

• IsolatedStorageScope is an enumeration that enables you to create and select a store with the appropriate isolation type.

The isolated storage classes enable you to create, enumerate, and delete isolated storage. The methods for performing these tasks are available through the IsolatedStorageFile object. Some operations require you to have the IsolatedStorageFilePermission that represents the right to administer isolated storage; you might also need to have operating system rights to access the file or directory. On Microsoft Windows NT, Microsoft Windows 2000, Windows XP, and Windows Vista, access control list (ACL) settings on the file can prevent you from accessing isolated storage. The Isolated Storage tool, Storeadm.exe, can also be used for simple store management such as listing or deleting all the stores for the current user.

For a series of examples that demonstrate common isolated storage tasks, see the how-to topics listed in Related Topics. Each example has a source file that illustrates one specific task. Instructions for setting up, compiling, and running are included on the main page of each example. The examples are provided in C# only.

Back to top

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.

• 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:

• Do not use isolated storage 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.

• Do not use isolated storage to store code.

• Do not use isolated storage 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.

Back to top

Back to top

System.IO.IsolatedStorage..::.IsolatedStorage

アプリケーションでファイルにデータを格納する場合は、ファイル名とストレージの場所を慎重に選択して、ストレージの場所が他のアプリケーションに知られたり、無防備に破壊されたりする可能性を最小限に抑える必要があります。 このような問題を管理するための標準的なシステムが適切な場所に用意されていないと、ストレージの問題点を最小限に抑える特別な技術の開発が複雑になり、信頼できる結果が得られません。

分離ストレージを使用すると、データは常にユーザーおよびアセンブリ別に分離されます。 アセンブリの発生元または厳密な名前などの資格情報によって、アセンブリの ID が決定されます。 また、同様の資格情報を使用して、データをアプリケーション ドメイン別に分離することもできます。

分離ストレージを使用している場合、アプリケーションはコードの ID のいくつかの側面 (発行元や署名など) に関連付けられた固有のデータ コンパートメントにデータを保存します。 データ コンパートメントは抽象概念であり、特定の記憶場所ではありません。データ コンパートメントは、データが格納される実際のディレクトリ位置が含まれている、ストアと呼ばれる 1 つ以上の分離ストレージ ファイルで構成されています。 たとえば、アプリケーションがそのアプリケーションに関連付けられたデータ コンパートメントを持ち、ファイル システムのディレクトリがそのアプリケーションのデータを実際に保存するストアを実装します。 ストアには、ユーザー設定情報からアプリケーション状態まで、どのような種類のデータでも保存できます。 開発者にとって、データ コンパートメントの場所は明確ではありません。通常、ストアはクライアントに常駐しますが、サーバー アプリケーションがユーザーを偽装することによって機能し、分離ストアを使用して情報を格納することもあります。 また、サーバー上の分離ストレージには、情報と共にユーザーのローミング プロファイルを格納できます。これにより、情報はローミング ユーザーと共に移動します。

ページのトップへ

分離ストレージを使用すると、完全な権限を与えられていないアプリケーションでも、コンピューターのセキュリティ ポリシーによって制御される方法でデータを格納できます。 分離ストレージは、慎重に実行する必要のあるダウンロードされるコンポーネントに対しては、特に有益です。 標準の I/O 機構を使用してファイル システムにアクセスするこの種のコード アクセス許可がセキュリティ ポリシーによって与えられるのは非常にまれです。 ただし、既定では、ローカル コンピューター、ローカル ネットワーク、またはインターネットから実行するコードには、分離ストレージを使用する権限が与えられています。

管理者は、適切な信頼レベルに基づいて、アプリケーションやユーザーが利用できる分離ストレージの容量を制限できます。 また、管理者は、ユーザーの永続的なデータを完全に削除できます。 分離ストレージを作成したり、分離ストレージにアクセスしたりするには、適切な IsolatedStorageFilePermission を持っている必要があります。

分離ストレージにアクセスするには、必要なすべてのネイティブ プラットフォーム オペレーティング システム権限が必要です。 たとえば、Windows 2000 では、どのユーザーにファイル システムを使用する権限を与えるかを制御するアクセス制御リスト (ACL: Access Control List) の要件を満たしている必要があります。 .NET Framework のアプリケーションには、分離ストレージにアクセスするためのオペレーティング システム権限が既にあります。ただし、アプリケーションがプラットフォーム固有の偽装を行っていない場合だけです。 偽装している場合は、アプリケーションが偽装しているユーザー ID に対して分離ストレージにアクセスするための適切なオペレーティング システム権限が与えられていることをアプリケーションで確認する責任があります。 偽装によるアクセスは、Web から実行またはダウンロードされたコードで、特定のユーザーに関連付けられたストレージ領域の読み取りや書き込みを行う場合には都合のよい方法です。

ページのトップへ

オペレーティング システムのファイル システムを使用して分離ストレージの変化を検査すると役立つ場合があります。 また、開発者が分離ストレージ ファイルの場所を知る必要がある場合もあります。 分離ストレージ ファイルの場所は、オペレーティングによって異なります。 いくつかの一般的なオペレーティング システムで、分離ストレージが作成されるルート位置を次の表に示します。 このルート位置の下の Microsoft\IsolatedStorage のディレクトリを検索してください。 ファイル システムの分離ストレージを表示するには、隠しファイルやフォルダーが表示されるようにフォルダーの設定を変更する必要があります。

ページのトップへ

分離ストレージに関する作業を実行するための主要なクラスとして、次の 3 つのクラスが用意されています。

• IsolatedStorageFile クラス。IsolatedStorage の派生クラスであり、格納されたアセンブリおよびアプリケーション ファイルの基本的な管理を提供します。 IsolatedStorageFile クラスのインスタンスは、ファイル システム内に存在する 1 つのストアを表します。

• IsolatedStorageFileStream クラス。System.IO..::.FileStream の派生クラスであり、ストア内のファイルへのアクセスを提供します。

• IsolatedStorageScope クラス。適切な分離タイプのストアの作成および選択を可能にする列挙体です。

分離ストレージ クラスを使用すると、分離ストレージの作成、列挙、および削除を行うことができます。 これらの作業を実行するためのメソッドは、IsolatedStorageFile オブジェクトを通じて使用できます。 操作によっては、分離ストレージを管理する権限を表す IsolatedStorageFilePermission が必要です。また、ファイルやディレクトリにアクセスするためのオペレーティング システム権限が必要な場合もあります。 Microsoft Windows NT、Microsoft Windows 2000、Windows XP、および Windows Vista では、ファイルに対するアクセス制御リスト (ACL: Access Control List) の設定によって分離ストレージへのアクセスが禁止される場合があります。 現在のユーザーのすべてのストアを一覧表示または削除するなどの単純なストア管理の場合は、分離ストレージ ツール (Storeadm.exe) を使用することもできます。

分離ストレージに関する一般的な作業を具体的に説明する一連の例については、「関連トピック」に示す「方法」トピックを参照してください。 それぞれの例に、特定の作業の実例としてソース ファイルを示します。 セットアップ、コンパイル、および実行のための命令は、各例のメイン ページにあります。 C# 言語で記述された例だけを示します。

ページのトップへ

分離ストレージは、さまざまな場面で使用されます。 最も区別しやすい 5 つの例を以下に説明します。

• ダウンロードされたコントロール。 通常の I/O クラスを使用して、インターネットからダウンロードしたマネージ コード コントロールをハード ドライブに書き込むことはできません。ただし、分離ストレージを使用することにより、ユーザーの設定やアプリケーション状態を永続化できます。

• 共有コンポーネント ストレージ。 アプリケーション間で共有されるコンポーネントで分離ストレージを使用することにより、データ ストアへのアクセスを制限できます。

• サーバー ストレージ。 サーバー アプリケーションでは、アプリケーションに対する要求を行う多数のユーザーに個別のストアを提供するために分離ストレージを使用できます。 分離ストレージは常にユーザー別に分離されているため、サーバーは、要求を行うユーザーを偽装する必要があります。 サーバーがユーザーを偽装する場合、データは、プリンシパルの ID (アプリケーションがアプリケーションのユーザーを識別するために使用する ID と同じ ID) に基づいて分離されます。

• ローミング。 アプリケーションでは、分離ストレージをローミング ユーザー プロファイルと共に使用することもできます。 分離ストレージとローミング ユーザー プロファイルを一緒に使用することにより、ユーザーの分離ストアは、プロファイルと共に移動します。

分離ストレージは上記の各シナリオで使用するのに適していますが、分離ストレージを "使用できない" 場合もあります。

• 分離ストレージは高度に信頼されるコード、アンマネージ コード、またはコンピューターの信頼されるユーザーからは保護されていないので、暗号化されていないキーやパスワードのような重要な機密情報の格納には使用しないでください。

• コードを格納する目的で分離ストレージを使用しないでください。

• 管理者が制御する構成設定や配置設定を格納する目的で分離ストレージを使用しないでください。 ユーザー設定は管理者が制御しないので、構成設定とは見なされません。

今日の多くのアプリケーションでは、データベースを使用してデータを格納し、分離しています。データベースを使用する場合は、データベースの 1 行または複数の行で 1 人の特定のユーザーのストレージを表します。 ユーザー数が少ない場合、データベースを使用するオーバーヘッドが重要である場合、またはデータベース機能が存在しない場合は、データベースの代わりに分離ストレージを使用できます。 また、データベース内の行よりも複雑で柔軟性のあるストレージがアプリケーションに必要な場合でも、分離ストレージによって実行可能な選択肢が用意されます。

ページのトップへ

ページのトップへ

System.IO.IsolatedStorage..::.IsolatedStorage