Debugging the Update Process for Windows Phone Apps
In my blog post entitled Testing the Update Process for Windows Phone Apps published last night we discussed the need for testing the update process for your Windows Phone applications. In this blog post we explore how to debug the update process for Windows Phone applications.
“It was the best of times, it was the worst of times…”
It was with these famous words that Charles Dickens began his book A Tale of Two Cities, “It was the best of times, it was the worst of times…”, while he was referring to one of history’s most explosive eras, he might have also been writing A Tale of Two Apps.
We continue discussing A Tale of Two Apps, the previous version of your Windows Phone application and the new update recently published to the marketplace.
Your excitement around submitting the update to your application, it passing certification and being published to the marketplace (e.g. the best of times…) has subsided following the realization that your application is crashing after users update the application on their phones (definitely the worst of times…).
In the previous blog post we discussed two tools that would prove useful in testing isolated storage issues, these are the Isolated Storage Explorer and Windows Phone Power tools created by Oren Nachman.
Let’s explore how you can use the Windows Phone Power tools to test and then debug issues related to the update process within Visual Studio 2010.
Windows Phone Power Tools – Connecting to Windows Phone Device or Windows Phone Emulator
We’ll start by deploying the initial version of the Windows Phone application using the Windows Phone Power tools with which you can deploy (and update) applications to either the Windows Phone Emulator or Windows Phone Device. I’ll use the Windows Phone Emulator although the process we’re describing will work just as easily with an actual device.
Windows Phone Power Tools – Installing the XAP
Once the Windows Phone Power tools are connected to the emulator or a device you can browse to the initial version of the application XAP that you’d like to test and then we’ll select to install.
One best practice that has proved very useful for me is to create a Library within Windows 7 called AppHub Submissions within which a safe copy of any files uploaded to the AppHub for certification can be place. You’ll see in the above figure this is where I’m able to easily install the previous version of my Stopwatch application to the emulator without worrying about whether I’m testing against an appropriate XAP built from the same source branch.
Windows Phone Stopwatch – Storing objects within Isolated Storage
Within this example we’ll be exploring an issue around isolated storage and so you would want to open your application and use it such that objects are serialized within isolated storage. Using the Windows Phone Stopwatch as an example, objects are saved to isolated storage during tombstoning and fast application switching.
With objects successfully saved within isolated storage it’s now time to update the application within the emulator (or device) such that we can then debug the update process using Visual Studio.
We cannot however simply debug the new build within the emulator (or device) as it will remove any previous versions of our application before running deploying the new version for debugging.
Windows Phone Power Tools – Updating the XAP
Using the Windows Phone Power tools however, we can update the existing application within the emulator (or device) without affecting any existing state stored within isolated storage. We therefore browse to the new XAP and update the application.
With the new version of the XAP deployed using the Windows Phone Power tools you can now test the update process although you cannot easily debug that process with Visual Studio.
If you have spent much time debugging on Windows with Visual Studio you might be wondering if we’re about to explain how to attach the debugger to the process running within the emulator (or device).
Given that the XAP has already been updated within the emulator (or device) using the Windows Phone Power tools we simply need to debug that code using Visual Studio, we don’t require Visual Studio to deploy the XAP as this would uninstall existing versions and remove any objects from isolated storage. Using the Visual Studio Configuration Manager, available by right clicking on the solution within the Solution Explorer, you can uncheck the Deploy checkbox next to the Build checkbox.
Visual Studio 2010 Configuration Manager
We can now start the application within Visual Studio as we otherwise would and assign breakpoints within the code where we’d like the debugger to stop executing such that we can examine the code that may be causing undesired behavior or crashes following the update.
Visual Studio 2010 Debugging Updated Windows Phone Application
“It was the best of times…”
We now have a repeatable way to test and debug the Windows Phone application update process.
I hope this blog post along with yesterday’s post entitled Testing the Update Process for Windows Phone Apps, have given you some useful information about how you can test and debug the update process.
Comments
Anonymous
December 12, 2011
I find it best to use WPTool to copy the contents of isolated storage to your local PC, deploy the updated XAP using Visual Studio, then copy the data files back to isolated storage. Now debug as normal (no need to uncheck "Deploy"). This gives you a repeatable scenario because you can easily copy the data files back to isolated storage without reinstalling the first version of the XAP. Part of an app update is usually to rewrite data files in isolated storage to a newer version. Having a copy of the original data files makes this a repeatable process.Anonymous
December 16, 2011
Great suggestion Steve, thanks!