With ARM devices like the Microsoft Surface and those from other OEMs, where it's not possible to run Visual Studio directly, it's good to know a few details on how to run/test apps on them.

First is remote debugging, described on http://msdn.microsoft.com/en-us/library/windows/apps/hh441469.aspx. It's quite easy to set this up–install the Visual Studio remote debugging tools, then select the Remote Machine option in VS on your dev machine and go from there. (Note: the link to the tools on the hh441469 page is broken as of this writing. Go to http://www.microsoft.com/en-us/download/details.aspx?id=38184 instead.) Just be sure that if you restart the ARM device, you need to restart the Remote Debugger (see the Start screen) for VS on your dev machine to pick it up on the network.

Testing on the ARM device specifically can reveal performance and responsiveness issues, as when you're doing an animation that's not running in the GPU (such one that affects CSS properties other than transform and opacity). It's also essential when you're working with sensors that aren't available on your dev box.  I also noticed with one app that running on the Surface revealed a latency issue in generating the layout, which was good to know of course!

Next, if you don't need to run the app in the debugger, and want to test as when it's directly installed, you can sideload the app. Just copy an appx package files created on your dev machine to the device, then run the PowerShell script. This does require that the ARM device has a developer license on it, which should happen when you install the remote debugging tools. (You might be prompted otherwise…I haven't tried this exact configuration so I can't say for sure.)

Next, there are occasions where you need to get a crash dump on an ARM device. You can enable generation of a local dump through some registry settings described on these two pages: http://msdn.microsoft.com/en-us/library/windows/desktop/bb787181(v=vs.85).aspx and http://msdn.microsoft.com/en-us/library/windows/desktop/bb513638(v=vs.85).aspx.

Finally, if you ever need to obtain a screenshot (especially for filing bugs and such), you'll quickly find that Print Screen keys and other standbys just aren't on the Surface, the touch keyboard, or the on-screen keyboard. The trick for Surface, at least, is to hold down the Windows button on the front of the Surface (the one that goes to the start screen) and press and release Volume Down on the side.

Addendum (4/23/13): In working with my own Surface I found today that my developer license on the device had expired, which resulted in an error on my dev machine when trying to use remote debugging. To remedy this, open an Administrator Command Prompt, the enter powershell, then from that prompt type show-WindowsDeveloperLicenseRegistration. That shows the UI that you normally see in Visual Studio to renew the license. Once I did that, and waited about 1-2 minutes for the renewal to take effect, I was able to run the remote debugger again.


4 Comments

  1. Julian Atanasoae
    Posted April 24, 2013 at 3:37 pm | Permalink

    Great article! I wish there was an Express version of Visual Studio just for Windows RT (I know that this is not the purpose of an ARM device), but it would have been very nice to write WinRT apps on it 🙂

    Still, these should be great web development devices (Notepad FTP=love).

    Kraig, what is the most advanced task you ever did on a Surface RT?

    • Posted April 24, 2013 at 5:25 pm | Permalink

      Not sure what you mean by “advanced”? I use the Surface for plenty of day-to-day activities, e.g. reading via the Kindle app, playing games, email, web, Netflix, managing SkyDrive, etc. Working very well for that.

      • Julian Atanasoae
        Posted April 25, 2013 at 5:38 pm | Permalink

        I mean, have you ever done any app development on it? Any remote PowerShell-ing or something like that? 🙂

        • Posted April 25, 2013 at 6:19 pm | Permalink

          No, I do dev work on a machine with two monitors, then run on the surface via remote debugging.