I stumbled upon a very useful tool in the Windows Phone SDK yesterday while chasing down a strange problem we encountered while testing upgrades of an app. Basically, the app’s settings appeared to get wiped during upgrades, which was not supposed to happen™.

Luckily, there was a tool available in the SDK called the Isolated Storage Explorer, which proved really useful. If you have the SDK installed, the tool should be available at: C:\Program Files (x86)\Microsoft SDKs\Windows Phone\v8.0\Tools\IsolatedStorageExplorerTool.

The tool has three main use cases, which we will dig further into below:

• Listing Files in Isolated Storage
• Reading Files From Isolated Storage
• Writing Files to Isolated Storage

Listing Files in Isolated Storage

Listing files is done using the dir command of the tool. An example command line would be:

ISETool.exe dir de {51b7c020-a817-4fde-8390-2c8374e50602}

Where:

• ISETool.exe is the tool itself
• dir is the command used to list files
• de indicates that we wish to read from a tethered device
• {51b7c020-a817-4fde-8390-2c8374e50602} is the product id from our app manifest

This command made it clear that something was definitely happening to the files in Isolated Storage during upgrades, event though we needed to dig a bit deeper in order to figure out exactly why.

NB: Instead of specifying de for device, we could have used xd in order to target an emulated device. I’m assuming that in order for the tool to work with a device, that device first has to be developer unlocked.

Reading Files From Isolated Storage

Reading files is done using the ts command. For example:

ISETool.exe ts de {51b7c020-a817-4fde-8390-2c8374e50602} C:\Temp\Snapshot

Where:

• ISETool.exe again is the tool itself
• ts is the command used to read files
• de indicates that we wish to read from a tethered device
• {51b7c020-a817-4fde-8390-2c8374e50602} is the product id from our app manifest
• C:\Temp\Snapshot is the location on the computer to save the files to

This command basically copies all the files from your app’s Isolated Storage to your computer, which is really useful since it not only allows for inspection and editing of those files, but also acts as a very handy backup mechanism.

In our case we were able to save a few snapshots of our data which helped us figure out what was going on:

• After a clean install of the original version
• After modifying and saving the settings
• After upgrading, but before starting the app for the first time
• After starting the upgraded app and discovering the settings are wiped

This means we had narrowed it down a bit: it didn’t appear to be the upgrade itself that was causing the problem, which was a huge relief, rather something during the first launch of the upgraded app. In other words, we had probably caused the problem ourselves, meaning we should be able to resolve it as well.

Writing Files to Isolated Storage

Writing files is done using the rs command. For example:

ISETool.exe rs de {51b7c020-a817-4fde-8390-2c8374e50602} C:\Temp\Snapshot\IsolatedStore

Where:

• ISETool.exe again is the tool itself
• rs is the command used to write files
• de indicates that we wish to read from a tethered device
• {51b7c020-a817-4fde-8390-2c8374e50602} is the product id from our app manifest
• C:\Temp\Snapshot\IsolatedStore is the location on the computer the files were saved to

NB: When reading files from the device, they are written to a subdirectory called IsolatedStore, which is created in the location specified. When writing files back again you explicitly have to specify this subdirectory yourself, as above.

This allowed us to skip the whole upgrade procedure during testing, as we could now simulate the procedure by simply installing the latest version and then writing a known good copy of the previous version’s settings to Isolated Storage.

This also allowed us to copy the settings from a release build on a physical device into a debug build on an emulated device, which meant we were then able to step through the upgrade process in the debugger. Once we were able to do this, the bug was quickly located and fixed.

Closing Thoughts

The ability to take and restore snapshots at will seems like it could be really helpful during systems testing, especially as it can be performed with actual physical devices provided they are tethered. Scripting the side-loading of an app and the restoration of a snapshot really shouldn’t pose too much of a problem either, which opens up for automated testing.

Being able to extract data at will from a device also means we now have a relatively painless mechanism for extracting debug logging information from devices “in the field”, meaning we should probably start looking into writing to physical debug log files in our Windows Phone apps too, even if the assumed requirement that the device in question be developer unlocked before this tool can be used prevents it from being universally useful.

Granted, only having to developer unlock a phone in order to gain access to its apps’ Isolated Storage also means sensitive data really needs both tamper protection and encryption. Developer unlocking a phone really isn’t all that difficult, nor time consuming.

The Isolated Storage Explorer page also has links to alternative versions of this tool, including a GUI version and a Visual Studio add-in.