Programming Windows Store Apps with C# (2014)
Chapter 15. Sideloading and Distribution
The most basic form of distribution is a test distribution. You would most likely use this if you wanted to give a partner, customer, or other members of the team a version of your app to test.
You’ll recall that when you start developing Windows Store apps in Visual Studio, the first thing that happens is you are asked to obtain a developer license. This is a form of sideloading. With a developer license installed, you can deploy any apps from any source onto that device.
There are two things to bear in mind with this. First, sideloading totally opens up the device to Windows Store malware by removing the deployment restrictions. Second, you are only permitted to use this approach for testing. You cannot use it for production deployment, and Microsoft is very strict about this. (One read of this is that Microsoft gets paid for the special licenses that you need to support production sideloading, but does not get paid for the developer licenses used for development sideloading.)
For my test, I created a separate virtual machine and installed Windows 8 Pro 32-bit. (I usually use 64-bit, and use 32-bit for variety more than anything.) What I wanted to do was have an entirely separate installation. I created the machine without a Microsoft Account association—that is, I used a local account to log on.
So let’s do this for your application. The first thing you have to do is set the product build mode to Release. There are two reasons for this. First, in order to get the app certified, you have to build it in release mode. Second, there are certain dependencies on Win32 DLLs, both specifically through inclusion of the Visual C++ Runtime Package and also through SQLite. As is standard, Windows does not come installed with the debug bit.
Once we’ve set our app to release mode, we can create a package. In Solution Explorer, right-click on the project and choose Store→Create App Packages. You’ll be presented with a wizard. In the first instance, we don’t want to upload the package to the Store. Figure 15-1 illustrates.
Figure 15-1. Indicating that we want to create a test package
The next page of the wizard will ask where we want to create the package, what our version number is, and which configurations we wish to deploy. Figure 15-2 illustrates my choices. Notice that I’ve included both x86 and ARM support. This refers all the way back to Chapter 3, where the inclusion of SQLite first demanded that we think about which processor architectures we supported. Inclusion of Bing Maps also has an impact of sorts here; that, too, requires us to manage the processor targeting explicitly.
Incidentally, we are not creating an x64 package here. If you recall the discussion in Chapter 3, I mentioned this wasn’t necessary, as an x86 implementation gets de facto coverage on x64 machines anyway. However, you certainly can create separate x64 packages if you wish. The one option we can’t choose is Neutral (aka Any CPU), because SQLite and Bing Maps prevent the Any CPU selection.
Figure 15-2. Defining package options
Click the Create button and the packages will be created. The page that follows suggests that you run the Windows App Certification Kit. Don’t do this—you don’t need to do it for testing. As we’ll see, it takes ages to run, and at this point it’s a waste of time.
On disk you’ll get a bunch of folders and files. Each folder relates to exactly one processor architecture package. Figure 15-3 illustrates the contents of one of the folders.
Figure 15-3. Contents of the ARM package folder
What you’ll see in the folder is:
§ A PowerShell script for installing the package.
§ An .appx file containing the actual application.
§ An .appxsym file containing debugging information.
§ A .cer file containing a certificate. This will be installed on the target machine to validate the .appx file on deployment.
§ The Add-AppDevPackage.resources folder containing string resources for, amazingly, the PowerShell install script (i.e., it’s nothing to do with your app).
§ The Dependencies folder containing other .appx packages that need to be installed along with your app. In our instance, it’s the Visual C++ Runtime Package.
All we have to do on the test VM is physically transfer that folder over to the target machine and run the PowerShell script. You can run the PowerShell script by right-clicking on the .ps1 file and selecting “Run with PowerShell.” The script actually needs admin rights to work, but the script will elevate rights for you if required.
Three things should happen next. If you don’t have a developer license installed on the machine, you’ll be prompted to get one. To test this, I created a new Microsoft Account at Outlook.com and used that email address. Next, the script will install the certificate included with the bundle. Finally, it will install the actual app. This last part is done using the PowerShell script Add-AppxPackage.
Not surprisingly, Remove-AppxPackage can be used to remove a package. Get-AppxPackage can be used to enumerate the packages on the device. These scripts are actually quite helpful—from time to time, you can get deployment failures. You can force-remove the bad package by getting the ID with Get-AppxPackage and then performing the removal with Remove-AppxPackage.
When the script is completed, you’ll find the app on the Start screen and you can run it as normal.
As mentioned, the likelihood is that if you’re doing this, you’re giving it to someone else to test. If you need to, you can use the Remote Debugging tools that we discussed in Chapter 6 to connect to the remote machine.
Using the Windows App Certification Kit
One of the big advantages of Windows 8 and Windows RT compared to other platforms is that you can do some of the validation for yourself using the Windows App Certification Kit. (This is often just called the WACK, pronounced “whack.”) This is a tool that performs static and dynamic analysis of your code. Importantly, it runs the same tests as the Windows Store backend does when you upload your code. To this end, it’s well worth running your code through the WACK before you submit it to the Store.
The reason I wanted to talk about the WACK before we talk about Store submissions generally is because of sideloading:
§ If you intend to distribute your app publicly through the Store, Microsoft will only do so if your app passes Microsoft’s run through its copy of the WACK. Thus, if you want to get your app on the Store, it’s worth validating it yourself first.
§ If you intend to distribute your app through production sideloading, but not through the store, it’s Microsoft’s recommendation that you still run the WACK.
I won’t go into what the WACK actually does, as these rules are likely to change. Any errors that you’ll get will be self-explanatory. However, the most common error that occurs when using the WACK is forgetting to set the solution to Release mode. Also, if you try to run the WACK with a Debug build, you can get false positives. In short, make sure you test a Release build.
All of this means that Microsoft will not allow a Debug build into the Store.
Distribution Through Production Sideloading
Now, let’s look at production sideloading, a more complex distribution method, because both the rules and the process are tricky. However, you have to do it in order to be properly licensed. The general process is that any Windows 8 or Windows RT device comes with sideloading capability switched off. You need to first turn this capability on, and then install your apps.
In this section I’m going to talk about Microsoft software licensing. You should know that I’m not an expert on licensing, and as a policy I don’t give advice on licensing. What’s presented here is guidance only—you should seek your own professional, qualified advice on licensing matters.
Windows 8 is available in three versions. The first is a vanilla, “home” version, which is simply called Windows 8. Ignore that version—we’re not talking about that at all. The other versions are Windows 8 Pro and Windows 8 Enterprise.
You can find information on this whole process on TechNet.
As I mentioned, we won’t be discussing licensing or talking about what is best—however, I do need to present a bit of information about licensing to complete the picture of how and when you can sideload.
Microsoft prefers to sell software to businesses under what it calls Volume Licensing (VL). When an end user buys Windows software off the shelf, or preinstalled on a computer, that is a retail license and outside of VL. The idea behind VL is that due to a volume purchase a business will receive a discount, easier management, and certain rights.
One VL program, Software Assurance (SA), is a program that allows for the buying of software on a quasi-subscription basis. Sideloading only works on Windows systems that are SA-licensed copies, or that fit into other programs that have similar privileges to those granted by SA. The Enterprise Edition of Windows 8 cannot be bought other than through SA. What this means is that if you go and buy 50 laptops from Dell, Lenovo, or whomever, those will come with retail licenses of Pro that you have to upgrade or replace with SA licenses. So, if your situation allows for sideloading, read on.
Turning on Sideloading on Windows 8
To turn on sideloading on Windows 8, you do one of these things. (I’ll talk about Windows RT in a moment.)
§ Take a Windows 8 Enterprise machine, join it to the Active Directory domain, and turn on a group policy item. This group policy item is called “Allow all trusted applications to install,” and can be found in Computer Configuration→Administrative Templates→Windows Component→App Package Deployment.
§ Take a Windows 8 Enterprise machine, don’t join it to the domain, and then activate what’s known as the enterprise sideloading product key.
§ Take an SA-licensed Windows 8 Pro machine (it doesn’t matter if it’s joined to the domain or not), and then activate the enterprise sideloading product key.
§ Take a non-SA-licensed Windows 8 Pro machine (it doesn’t matter if it’s joined to the domain or not), fix up the license to make it “comply with the rules,” and then activate the enterprise sideloading product key.
It’s this “complying with the rules” step that’s difficult. Essentially, Microsoft wants you to be on SA. As of the time of writing, you can make a non-SA Pro license similar enough to an SA license by doing the following:
§ Enlisting the device in Microsoft Intune. Intune is a cloud-based service that provides basic mobile device management (MDM) features. We’ll talk about this again later.
§ Enlisting the device in a Virtual Desktop Access (VDA) license.
§ Enlisting the device in a Companion Device Licence (CDL) license.
If you don’t know what VDA or CDL licenses are, don’t worry—most people don’t. It just illustrates why you’d likely need specialist advice if you need to do this.
If you can’t do any of those things, the stopgap is to buy the enterprise sideloading key. For reference, as of the time of writing, you could buy enterprise sideloading product keys in packs of 100 for $3,000 (i.e., about $30 per unit).
However, there is a risk associated with sideloading. Note that the description on the group policy items reads as follows:
If you enable this policy setting, you can install any trusted app package.
A trusted app package is one that is signed with a certificate chain that
can be successfully validated by the local computer.
Once you have the sideloading configured, you can install the app.
The expectation from Microsoft is that you do this installation through Intune. For Windows RT, this is essentially the only practicable way to do it. If you use Intune, what will happen is that you’ll configure the device such that it is associated with your company’s Intune account. You upload the application binaries to Intune and configure the policy items to decide who gets the app, and then the app is either automatically or manually downloaded by the users.
If you don’t want to use Intune, there are two other ways that you can get your app installed.
The first way is to do as shown before and use the PowerShell scripts to install the apps. You can do this manually, or you can configure domain logon scripts to run the PowerShell scripts. (This would obviously be less easy with Windows RT, as you don’t have domain logon on Windows RT.)
The second way to do this is to bake the app into any desktop image that you push out to desktops in your business.
Distribution Through the Windows Store
So far we’ve considered delivery of test builds for debugging, or private builds of the app for internal use. Many people will want to deliver their apps through the public Windows Store.
I’m not going to go through all of the whys and wherefores of getting your app onto the Store—for one thing most of it is obvious, and for another Microsoft will likely keep changing the details of the process, rendering obsolete any screenshots that I present. However, I will take you through the fundamentals.
You will need a developer account on the Store. You will need to pay for this, although as of the time of writing MSDN subscribers get a paid developer account for free.
You’ll need to “reserve the name” for your app on the Store website. This tells Microsoft that you intend to use the name and stops others from claiming it. You can reserve a name for 12 months. If you don’t use it in that period, others can claim it.
Once you have reserved the name, you can associate the Windows Store project in Visual Studio with the name in the Store. To do this, right-click on the project in Solution Explorer and select Store→Associate App with the Store.
You’ll be asked to log in to your Store account. Once you do this, you’ll be asked to select the name of the app from the names registered against your account. In Figure 15-4, you can see that I have reserved the name StreetFoo.
Figure 15-4. Associating the app with the store
Click Next, and then Associate to associate the project. This involves changing the project settings, and also downloading and installing your private developer certificate from the Store.
If you look in the Packaging tab of the manifest editor, you’ll see that the application details have been changed to those you entered on the Store. In Figure 15-5, you can see that the name of the publisher is given as AMX Software Ltd (the name of my business), and that the package name is given as mbrit.StreetFoo. These replace any placeholder values used for debugging.
Figure 15-5. Modified manifest settings
The name mbrit.StreetFoo is actually a mistake I made when registering the name in the Store. Ideally, this should be a Java-style reversed domain name. My domain is mbrit.com, so the name should really be com.mbrit.StreetFoo.
Once you’ve done the association, you need to go through the packaging steps. This is essentially the same process we went through at the beginning of the chapter. However, this time when you start the wizard, choose Yes for the question “Do you want to build packages to upload to the Window Store?” Other than that, the process is the same.
With the packages created, go back onto the Store and complete the store listing. As part of that process, you will be invited to upload the packages. Upload the packages for both the x86 and ARM processors. Figure 15-6 illustrates.
Figure 15-6. Uploading the packages
And that’s it! Once you complete the listing, Microsoft will set about validating the app. Once it’s satisfied that the rules have been followed, your app will be live in the Store.