But since XNA is so awesomely portable, you are also making a Windows version of your game (perhaps you want to ship it on Windows, or maybe you just want to use Windows tools to debug and profile your Xbox or phone game).

So we make a new Windows game project. In our Initialize method, we add:

It compiles! (which proves this API must be properly portable, right? 🙂

But when we run on Windows, we get an IsolatedStorageException with the message "Unable to determine application identity of the caller."

What gives?

Isolated storage on Windows actually provides several Get*Store* methods, which differ in how the storage location is identified. Some are per-user, others per-machine. Some use the identity of the calling assembly, or the current AppDomain, or the current website, to isolate the save location.

Windows Phone only supports per-user per-application storage (via GetUserStoreForApplication), so it does not include all the other Get*Store* methods that are available on Windows. But in order to save data per-application, the current application must have a well defined identity. That is always the case on Xbox or Windows Phone, where applications are deployed from packages that include manifests with name and version information. But Windows can directly run arbitrary .exe files, which may not have an application identity as required by this call.

One option is to use a different isolated store on Windows. We can wrap this platform difference in a helper method:

Now GetUserStoreForApplication will work when we F5 debug inside Visual Studio (but will still fail if we run the application standalone, such as via Ctrl+F5, until we properly install it using ClickOnce).

Beware of a Visual Studio bug. If you turn on "Enable ClickOnce security settings" but not "Enable the Visual Studio hosting process", you get an error message:

"The security debugging option is set but it requires the Visual Studio hosting process which is unavailable in this debugging configuration. The security debugging option will be disabled. This option may be re-enabled in the Security property page. The debugging session will continue without security debugging."

That sounds fair enough, but Visual Studio doesn't actually do what the message says :-) In fact it leaves your project in a broken state, where GetUserStoreForApplication will continue to fail even after you turn "Enable the Visual Studio hosting process" back on!

If this happens to your project, you can fix it by deleting the .csproj.user file that is stored alongside your main .csproj.

From what someone else told me while referencing this thread, this method guarantees the stored data will reside next to the game binary, and any time you remove the drive the game is on it will crash (at least I would assume).

Some reviews I read were concerned about saving data without allowing the user to select a device (which is what this seems to allow), but I think it would make small save files much easier to implement.

So yeah I'm curious as well if there are any potential pitfalls of using this in Peer Review?

I just found a caveat with the ClickOnce solution. If you do this, you cannot use the CLRProfiler to track memory allocations (it crashes when trying to access the store). This leaves us to use the GetUserStoreForDomain() solution.