From the MVPs: Different deployment options in Windows 8

Here’s the 22nd in our series of guest posts by Microsoft Most Valued Professionals (MVPs). (Click the “MVPs” tag in the right column to see all the articles.) Since the early 1990s, Microsoft has recognized technology champions around the world with the MVP Award. MVPs freely share their knowledge, real-world experience, and impartial and objective feedback to help people enhance the way they use technology. Of the millions of individuals who participate in technology communities, around 4,000 are recognized as Microsoft MVPs. You can read more original MVP-authored content on the Microsoft MVP Award Program Blog.

This post is by Peter Ritchie, a Visual C# MVP. Than ks, Peter!

If you're used to some other app store or hub/portal-based deployment models, you might think that an externally hosted "store" might be the only option for deploying Windows 8 apps. That's simply not the case.

Windows 8 isn't just about consumer footprint devices; it's also about corporate and line of business (LOB) applications. Windows 8 is optimized for consumer electronics like touch laptops and tablets, but these form factors are also extremely important for a variety of organizations and businesses. There are a variety of businesses that can get a huge benefit out of a small, simple, touch device like a tablet. Vertical businesses like medical, on-site-customer relationship, service-oriented, etc.

If you think that the deployment option for Windows 8 applications will be the Windows Store, you might think that vertical LOB application deployment would be extremely difficult. Either you simply couldn't allow your app into the store for public consumption or you'd have to manually sideload a device at a time. That would be very limiting for larger organizations; but there are other options.

There are several options for deploying business-style applications. The first, of course, is through the Windows Store. The store is useful for situations where you have a service or subscription-based service and you want to provide an application for random customers to download and use your service. That app may be “non-functional” unless the user is paying for your service. You don't limit who uses your app and you don't really want to create an infrastructure to deploy to your customers, so the Windows Store fits the bill (assuming you can abide by the app certification rules). There’s lots of good content about deploying to the store, so I won’t go into detail about that.

The second choice is sideloading. This is where you manually install app packages onto devices. There are different options for doing this, but this could be the execution of a PowerShell script to install an application package. This might be useful in limited situations where you don't want to develop or manage a deployment infrastructure but don't want your app to be publically available. Useful for a small number of deployments but likely limiting if you have a large number of deployments.

There are a couple scenarios for sideloading. The first is obviously to use Visual Studio to deploy the app to a specific computer. This requires that remote debugging tools are installed on the remote computer. The remote tools are generally found in your Visual Studio 2012 install’s Remote Debugger directory (e.g., C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\Remote Debugger) but can also be found in the Microsoft Download Centre. There are various versions depending on the processor you are using. Once installed, the remote debugging monitor should start up (you’ll have to re-run this if you exit or reboot), which should appear as follows:

clip_image002

Once that’s running, you can configure your project to deploy to that remote computer by selecting the Remote Machine option in the Debug Target toolbar item in the Standard toobar, for example:

clip_image004

Which will then present you with a form to configure the details of the remote machine:

clip_image006

You can enter the name of the computer you want to deploy to in the Manual Configuration section, or you can wait for it to be found and select it.

The second sideloading scenario is geared towards deploying LOB apps. This assumes you’re running in an organisation on a domain. You must first enable sideloading by enabling Allow all trusted applications to install in the domain’s Active Directory Group Policy as well as the local computer. For example:

clip_image008

Although sideloading to a non-domain computer is supported, you’re required to get a sideloading product activation key, and I’m unable to find any detail on how to do this.

Once enabled, you should be able to execute the add-appxpackage powershell cmdlet after copying the appx file to the computer you want to deploy to. For example:

add-appxpackage C:\app1.appx –DependencyPath C:\winjs.appx

The third option is to create your own deployment portal so that people who have access to your hub and selectively download "approved" applications, which can be custom developed applications (like LOB) or existing (3rd party) Windows Store apps that have been vetted, approved, etc. Updates and approvals are done manually by the business, custom to the business based on their needs and requirements.

There are multiple companies leveraging these various options. Citrix, for example, provides some applications in the Windows Store for the average Citrix user to download and install applications that integrate and access a particular business’s Citrix infrastructure (and “non-functional” for users who don’t have access to this type of infrastructure, despite downloading the app). Citrix Receiver, for example. SAP is another company that's leveraging store apps to provide integration into SAP to do things like expenses and candidate/interview management.

Now, despite deployment options that don’t use the Windows Store directly, these are still considered "Store applications". Sometimes these types of apps are called Modern UI apps. It’s a bit confusing; but once you get the terminology down, it’s not too bad.