我最近发现，在.NET中的 IsolatedStorage 设施，并且我不知道什么时候我应该使用他们为我的应用程序数据对何时应使用（例如） Application.LocalUserAppDataPath 。

这是我注意到一件事是，应用程序的WinForms应用程序之外不存在，所以它似乎 IsolatedStorage 可能是有意义的，需要一些特定的存储，特别是如果该库可能会被同时用于网络应用程序和WinForms应用程序类库。这是唯一的区别点，还是有更多的吗？

（按照规定，达直到现在，我所做的应用程序提供了一个文件流的库当库可能需要某种形式的外部存储---在一般情况下，我不喜欢的想法有某种外部的调用者的上下文状态的图书馆。）

解决方案

IsolatedStorage有你选择它了几个有趣的功能，可能使：

即使是非常低的受信任的应用程序（如点击一次）可以访问独立存储。并非所有的应用程序都可以访问应用程序数据。取决于施加在应用的安全策略，IsolatedStorage也可以限制，但它通常比应用程序数据/文件系统更容易获得。

IsolatedStorage存储需求可以通过管理员策略控制。

您不必知道在哪里或如何独立存储数据的存储。它具有用于访问其上的所有系统可以完全忽略，它是存储在基础路径一个统一的API。当你所指出的，这是对于可能不知道如何主导应用存储数据的库非常有用的。

您也可以有数据独立存储中存储的数据发生变化的隔离级别非常容易。请参见的IsolatedStorageScope值以获取更多信息。这是它的名字，所以我想我应该列出了这一点先:)

在下行：

在IsolatedStorage有一些显着限制的数据可以存储在那里的​​数量。例如，应用程序preferences将被罚款，但它是不适合的文件。

一些有用的链接：

介绍独立存储 执行独立存储任务

I've recently discovered the IsolatedStorage facilities in .net, and I'm wondering when I should use them for my application data versus when I should use (e.g.) Application.LocalUserAppDataPath.

One thing that I've noticed is that Application doesn't exist outside of a winforms app, so it seems that IsolatedStorage might make sense for a class library that needs some specific storage, especially if that library might be used by both a web app and a winforms app. Is that the only distinguishing point, or is there more to it?

(As a rule, up 'til now, I've made the app provide a file stream to the library when the library might need some sort of external storage--- in general, I don't like the idea of a library having some sort of state external to the caller's context.)

解决方案

IsolatedStorage has a couple interesting features that might make you opt for it:

Even very low trusted applications (such as click-once) can access isolated storage. Not all applications can have access to AppData. Depending on the security policy imposed on the application, IsolatedStorage can also be limited, but it usually is more accessible than AppData/file system.

IsolatedStorage storage requirements can be controlled by administrator policy.

You don't have to know where or how isolated storage data is stored. It has a uniform API for accessing it on all systems you can completely ignore the underlying path that it is stored in. As you noted, this is very useful for a library which may have no idea how the hosting application stores data.

You can also have data stored data in isolated storage with vary levels of isolation very easily. See the IsolatedStorageScope values for more information. This is its namesake, so I guess I should have listed this point first :)

On the downside:

IsolatedStorage has some notable limits in the amount of data you can store there. For example, application preferences will be fine, but it is not appropriate for documents.

Some useful links:

Introduction to Isolated Storage Performing Isolated Storage Tasks