Debugging Windows Store apps in the Simulator is a pretty slick idea that mostly works.
Mostly.
A limitation of the Simulator is that it runs as a child session of the current user session. This short straightforward answer on Stack Overflow explains.
The problem with that for me is three-fold. The first is just annoying: any apps that I have that run on system startup are launched when the simulator starts. Some of these apps have problems with running multiple instances as the same user. I imagine that they try to lock some resource (a file, etc.), but since that is already locked, I get a lot of error dialogs in the Simulator. I get around this using a script I wrote to kill the offending processes in the child session. It’s annoying, but I can work around it.
A second problem is that my user has permissions that another user might not have. I do run Visual Studio as local administrator (disclaimer: I know the arguments against this), but that’s not entirely what I’m talking about. Network resource permissions and other such differences could also cause issues.
Selfishly, I have a third issue that would be solved by allowing the Simulator to run as a different user. I take a lot of screenshots. When I want to take a screenshot of my Start screen for use in some documentation, or my upcoming book, I don’t necessarily want all of my apps/tiles in the screenshot. I’m not so worried about people seeing what I’ve got going on, although no one really needs to know my next appointment, latest email subject line or recent tweets that are displayed on the tiles. The bigger concern is that those tiles add clutter that could distract and/or confuse the person that will be reading my documentation.
One possible solution is to use Visual Studio’s Remote Debugging functionality to connect to a virtual machine running, described in the previously mentioned Stack Overflow answer. This goes a long way to eliminate the issues I’ve raised, but it has one drawback. I can no longer use the Simulator tools such as spoofing geo-location or touch mode or easy way to change screen resolutions.
My current solution is to continue to use the Simulator as it is. When I first launch it, I switch to the desktop and run my utility to kill any processes that cause errors with multiple instances. This is where I do my primary testing and documentation. When I need more isolated testing, then I use Remote Debugging to debug on my Surface RT. This is probably the most correct way of debugging but does require me to have both my laptop and Surface running at the same time.
All in all, debugging Windows Store apps is a good experience, but a few changes to the Simulator could make it nearly perfect.
If you’ve run into similar issues debugging Windows Store apps, what have you done to fix or work around them?