locked
Is there any way to debug a fullscreen Metro application more comfortably

    Question

  • As a very practical demonstration of why -- at least for the x86 desktop -- we need a way to run Metro apps in windows, I'm finding that debugging the apps is excruciatingly painful.

    Going back and forth between VS11 and the app being debugged is extremely awkward, and the simulator is much too slow in many situations. Debugging DirectX can also be extremely painful when there are bugs associated with video device resets -- which happen every time you want to so much as look at the debugger.


    the cows are here to take me home now...

    Thursday, April 12, 2012 4:34 AM

All replies

  • Hi Rei,

    There are several options for debugging full screen apps in general and Metro style apps in particular. Which is best will depend on your specific circumstances:

    Multiple monitors: you can run your debugger on one monitor and the app on another. This is generally pretty easy, but has the disadvantage that the debugger interferes with focus on the debugged app. It is still a good solution in many cases, and I usually use this when debugging touch so I can use my touch monitor.

    The simulator: this is what I use in most cases (even on my multi-monitor system), although I understand that you're not fond of it.

    Remote debugging (either to a physical or virtual machine): This may be a good solution for you if the simulator is too slow. Windows 8 has some great connectivity upgrades over older OSes. I used to do this frequently for desktop apps to avoid focus issues caused by the debugger, but with the simulator I rarely need to do so for Metro style apps. It is handy when I have a touch slate available but don't have a touch monitor.

    --Rob

    Thursday, April 12, 2012 11:16 PM
    Owner
  • Hi Rei,

    There are several options for debugging full screen apps in general and Metro style apps in particular. Which is best will depend on your specific circumstances:

    Multiple monitors: you can run your debugger on one monitor and the app on another. This is generally pretty easy, but has the disadvantage that the debugger interferes with focus on the debugged app. It is still a good solution in many cases, and I usually use this when debugging touch so I can use my touch monitor.

    The simulator: this is what I use in most cases (even on my multi-monitor system), although I understand that you're not fond of it.

    Remote debugging (either to a physical or virtual machine): This may be a good solution for you if the simulator is too slow. Windows 8 has some great connectivity upgrades over older OSes. I used to do this frequently for desktop apps to avoid focus issues caused by the debugger, but with the simulator I rarely need to do so for Metro style apps. It is handy when I have a touch slate available but don't have a touch monitor.

    --Rob

    All of these options, except the simulator, which I already answered is too slow, require additional hardware and/or additional OS licenses.

    As a student, I can't afford that.

    I hate to bring up design philosophy on a technical forum, but there's something seriously wrong with this situation.


    the cows are here to take me home now...


    Thursday, April 12, 2012 11:19 PM
  • I think MS have to improve Simulator for Windows Store app in VS 2012. It's really slow!!!

    My CPU is Asus F81Se, Core 2 duo 2,67Ghz; 4GB Ram bus 667; VGA 512MB. Strong enough? But I've started Simulator 15mins ago, and now it's still BOOTING!

    MS should did better!

    Thursday, September 27, 2012 8:06 AM