OakLeaf Systems: Installing Windows Store Apps on a Microsoft Surface for Windows RT Tablet

Sunday, December 30, 2012

Installing Windows Store Apps on a Microsoft Surface for Windows RT Tablet

My (@rogerjenn) Windows Azure Mobile Services Preview Walkthrough–Part 5: Distributing Your App From the Windows Store post of 9/22/2012 described issues raised during Microsoft’s testing for hosting the OakLeaf ToDo sample application in the Windows Store. Testers reported the OakLeaf ToDo app’s failure to operate as expected during repeated attempts to have it listed.

In order to test the app under conditions that better simulate Windows Store testing, I purchased a Microsoft Surface with Windows RT (a.k.a. Surface RT) tablet computer on 12/19 and received it on 12/20/2012. My initial tests were of a C# SharePoint App with a Visual Studio LightSwitch HTML 5 Client Preview 2 UI autohosted in Window Azure. My LightSwitch HTML Client Preview 2: OakLeaf Contoso Survey Application Demo on Office 365 SharePoint Site and Running the SurveyApplicationCS Demo Project under Windows 8 RT on a Microsoft Surface RT Tablet posts describe the SurveyApplicationCS project.

Following are posts by Magenic’s Rocky Lhotka and Larry Louisiana that describe the processes I’ll use for testing the OakLeaf ToDo Windows Store app. I’ll update this post with links to the test results when completed.

Updated Rocky Lhotka’s article on 12/30/2012 with a note and screenshot showing that an administrator can’t execute PowerScript’s Set-ExecutionPolicy unrestricted command.

Rockford Lhotka (@RockyLhotka), Magenics CTO and Principal Technologist, explained Testing a WinRT app on a Surface RT in a 12/20/2012 post to his blog:

A colleague of mine at Magenic recently posted on how to deploy and debug a WinRT app on a Surface RT [see post below.]

Another alternative is to install the app onto the Surface device via PowerShell. This won’t attach the debugger, but is often an appropriate solution for people who are just testing the app (QA testers, colleagues willing to provide feedback, etc.).

This is a multi-step process. At a high level it goes like this:

Developer packages the WinRT app to a folder on their hard drive, then puts the package on a network share or USB key, etc.

Tester unlocks PowerShell on their device (this is a one-time thing)

Tester gets the WinRT app package and runs a PowerShell script to install the app on their device

Creating the Package

The developer needs to create a distributable package for the app. This is done by right-clicking on the WinRT project in the Visual Studio solution explorer, and choosing Store –> Create App Packages.

This brings up the Create App Package wizard. The first question is whether you want to deploy the the store, and the answer in this case is No.

Next, you’ll be asked where to create the package, how to create the package version number (different from the app version number) and what platforms to target.

The Neutral architecture in Release (Any CPU) allows testing on Intel and ARM devices.

When the Create button is clicked, the project is built and packaged, with the results placed in the specified folder.

The top level folder contains an appxupload file that you can safely ignore (it is used for uploads to the store). It also contains a sub-folder with the actual app package.

These are the files you must make available to the tester. You can put these files on a network share, a USB key, a SkyDrive folder, or any other location where the tester can gain access. The Add-AppDevPackage.ps1 file is the PowerShell script the tester will run to install the app.

Unlocking PowerShell

The tester’s device must be able to execute PowerShell scripts before they can install the app. By default PowerShell has security settings that prevent scripts from executing. This TechNet article discusses running PowerShell scripts. In summary, you need to open PowerShell as Admin and run this command:

Set-ExecutionPolicy unrestricted

Note: Users with an Administrative account can’t execute the above command. See screen capture below. You are given the opportunity to authorize the operation during PowerScript execution.

Be aware that this allows execution of any script, so you do assume some risk by enabling this policy.

Once this has been done your test device is now able to install WinRT apps by executing the PowerShell script generated by Visual Studio.

Installing the App

On the test device you must have access to the contents of the package folder created by the developer in Visual Studio. You might get those files from a network share, a USB key, or other location.

Simply execute the Add-AppDevPackage.ps1 file in PowerShell to install the app.

The script will ask permission to run.

If this device does not have a side-loading unlock key (MAK or developer key), you will be asked if you want to get a developer key. You should answer yes and walk through the wizard to get a developer key for this device. This step will require you to enter your Microsoft Account email address and password. The resulting key will expire after a short period of time (currently three months).

The PowerShell script will then ask for permission to install the certificate for the app. If you’ve already installed the certificate (perhaps you are installing a newer version of the same app) the script will skip this step.

Once the certificate is installed, the script will install the WinRT app itself.

At this point the WinRT app is installed and its tile should appear on the start screen along with all other apps installed on this device.

The user may now run the app like any other app.

Once the developer key for this device expires the app will stop working. Obviously the intent of this installation approach isn’t for the user to run the app forever, but rather so they can test it and provide feedback during the development process.

Here’s the screen shot showing that Surface RT administrators can’t access the registry key necessary to enable unrestricted script execution.

Larry Louisiana (@LarryLouisila, a.k.a. Ely Bob) described Step by step deploying App[s] to Surface in a 12/19/2012 post:

Magenic recently gave out it’s Christmas present, so the first thing I did was try to deploy code to it.. here is how you can:

Download the ARM version of Remote Tools for Visual Studio 2012 to your Surface (I believe that you’ll need to be running Windows 8 on your development machine). Install it.

Have something to Deploy, I’m using the DirectX marble maze game sample from MSDN.

On your Surface start the Visual Studio Remote Debugging monitor.

You will need to know your Surface’s IP address I used “IP Address” by Jujuba Software (it’s free). [Hyperlink added.]

Jujuba IP Address Screen Shot

Once I Installed this, I opened it up and copied the IP that it displayed for my local IP address (put that in a .txt file on my desktop). You will need that for later.

Once you have your IP address saved and aside open the Marble Maze solution in Visual Studio.

Next go into the solution settings and Set your solution to ARM.

Then go into the Project Settings and set your IP (local) and set it to ARM if those settings didn’t propagate)

You’re almost there, Now just select Remote Debugging in the Debug Drop-down and click debug.

If you’re using a machine attached to another Domain you’ll be asked to supply login credentials for your Surface. Otherwise you will just deploy normally. Your login credentials for your surface device are the machine name followed by your full live email, So for this example it would be Centepede\{me}@hotmail.com.

If you don’t have [?] and once the package deploys (might take a while the first time to get all the references up to date on your Surface) You will see the Marble Maze Splash Screen. and if you go back to your desktop you will see:

Based 2[on] the original MSDN Blog.