Deployment

Windows desktop applications have traditionally been deployed to end users with a combination of dedicated installer programs, file-copy mechanisms, and command-line batch files. For Windows Store apps, the options and mechanisms available for distributing applications are a little different and may be new to traditional desktop application developers.

As the name implies, the most common way users will obtain Windows Store apps is through the Windows Store itself. Developers can publish either free apps or apps that are sold for a fixed fee, and apps that are for sale can opt to include support for preview or trial modes. In addition to the revenue that can be realized through an app’s initial purchase, developers can also make money throughout the lifetime of the app through both in-app purchases as well by integrating with one of several advertising frameworks. As has been discussed throughout the book, any apps submitted to the Windows Store must first go through a standard approval process before they are made available to the public, ensuring that the apps in the store are not malicious, comply with Microsoft’s published requirements, and offer end users all of the necessary privacy and system-state protections.

Developers aren’t restricted to only deploying through the public Windows Store, which is particularly interesting and valuable for line-of-business applications. There are mechanisms available to deploy Windows Store applications directly to end-user devices focused on several scenarios. However, these mechanisms do involve more than just simple file copying, as will be discussed later in this chapter.

31. The Store Menu in Visual Studio Express 2012 for Windows 8

The Windows Store

The Windows Store offers several opportunities for developers. Apps published through the Windows Store are visible in a single central location and can reach more than 200 markets across the globe in over 100 different languages. The store itself implements the Search contract that was discussed previously, allowing users to find their way to apps of interest both via the store layout and through searching for key terms. Furthermore, descriptions of apps published in the Windows Store can be viewed over the web, and the content provided to describe the apps is exposed to search engines, making it easier for end users to discover apps they may be interested in.

As mentioned previously, there are several ways that Windows Store apps can be sold. The apps themselves can be assigned a wide array of prices within a predefined set of tiers. These include (prices in US dollars):

• Free
• $.50 intervals from $1.49 through $4.99.
• $1.00 intervals from $4.99 through $49.99.
• $5.00 intervals from $49.99 through $99.99.
• $10.00 intervals from $99.99 through $299.99.
• $50.00 intervals from $299.99 through $999.99.

For apps sold through the Windows Store, Microsoft’s current model is that 70% of the revenue is passed along to the app owner until the app achieves $25,000 in revenue, after which the share percentage jumps to 80%. Furthermore, as has been mentioned and will be explored more thoroughly throughout this chapter, apps can include trial modes, built-in purchases through either the Windows Store or other means, and advertising.

The process for submitting an app to the Windows Store is not overly complex and typically involves:

21. Obtaining a Windows Store developer account.
22. Reserving an app name and providing some app settings.
23. Building, testing, and uploading the app.
24. Providing publishing information about the app for end users.
25. Submitting the app to the store for certification.

These steps will be discussed in the following sections.

Windows Store Developer Accounts

Before starting the process of submitting apps to the Windows Store, it is necessary to register for and obtain a Windows Store developer account that must be associated with a particular Microsoft Account, which is the name now used to describe what were formerly Hotmail or Windows Live accounts. There are two Windows Store developer account types: individual accounts and company accounts. Company accounts require additional verification to ensure that the applicant is authorized to create an account on behalf of the company, and in the US require an Employee Identification Number, also known as a Federal Tax Identification Number issued by the Internal Revenue Service. Individual accounts in the U.S. require a Social Security Number. Only apps submitted through company accounts can include the Enterprise Authentication, Shared User Certificate, and Documents Library Access capabilities. Because of these additional capabilities, apps submitted through company accounts may sometimes go through a more rigorous certification review than those submitted by individual accounts.

Regardless of the specific account type, the process for creating a Windows Store developer account can be started through the Open Developer Account command in the Store menu in Visual Studio Express, or by navigating to https://appdev.microsoft.com/StorePortals/Account/Signup/Start.

As of this writing, the standard fee charged for an individual developer account is $49 per year, and $99 per year for a company account. A table describing fees for other countries is available at http://msdn.microsoft.com/en-us/library/windows/apps/hh694064.aspx.

Registering and Submitting an App

Once a Windows Store developer account is created, an app can be submitted to the Windows Store. Apps are submitted and managed through the Windows Store Dashboard, which is available online at https://appdev.microsoft.com/StorePortals. The Dashboard provides a list of existing app registrations and links for managing and viewing account information.

Reserving an App Name and Pre-Upload Settings

From within the Dashboard, the app submission process is broken down into several discrete steps that focus on providing different app information and content. The first step in this process is to create and reserve a name for the app, which must be completed before any of the other steps can be started. The app’s name must be unique across all of the apps in the store, and while an app can have language-specific names, each of the names must be unique across all of the languages in the store. Furthermore, the app name that is selected in the Windows Store registration process must be used as the DisplayName value in the application’s manifest file. An actual app must be submitted for a reserved name within a year of the reservation, or the reservation will be lost. An app name can be reserved by either selecting the Reserve App Name command from the Store menu in Visual Studio Express, or selecting the Submit an App link from the Dashboard. In either case, a webpage will be displayed that lists the steps necessary to submit an app—selecting the link on the App Name step will navigate the browser to a page where the app name can be provided.

Once an app name has been selected, Visual Studio can be used to associate an app with the store. Selecting the Associate App with the Store command from the Store menu in Visual Studio Express (or from the Store entry in the Project context menu in other Visual Studio editions) will bring up the Associate Your App with the Windows Store wizard. This wizard will ask for the Microsoft account credentials associated with a Windows Store developer account, and list the application names registered with that account. Selecting one of the applications and clicking Associate will update the Package entries in the application’s manifest file:

• The package name will be updated to match the unique name being used in the Windows Store.
• The digital certificate file that is used to sign the application during development will be updated with published information that corresponds to the Windows Store developer account. Note that this is not the final certificate that will be used to sign the application when it is available in the Windows Store.
• This combination of updates will create the Package family name entry that uniquely identifies the application that is consistent with the one that will be made available when the application is added to the Windows Store.

Beyond the ability to associate an app with the store, once an app name is selected, the other pre-upload application registration steps can be completed. These steps include:

• Selling details: This is where a price is selected for an app or an indication is made if the app is to be available free of charge. If a price is selected for the app, the app can be configured to also offer a trial mode which will allow the app to be downloaded for free and potentially later upgraded. Trial modes can be set to either never expire or to expire after a particular duration of time. This screen also offers the ability to indicate the countries to which the app should be made available, the earliest app release date if one is desired, and the category and subcategory in which the app should appear within the Windows Store. Finally, some minimum system DirectX and RAM requirements may optionally be specified, as well as whether the app is designed to meet accessibility guidelines. More information about application accessibility can be found at http://www.microsoft.com/enable/.
• Advanced features: This is where settings related to providing push notifications may be obtained. Settings related to integrating with authentication provided by the Live Connect API can be both set and obtained here. Furthermore, this step includes the ability to register product IDs for in-app offers to be sold through the Windows Store. In-app purchases will be discussed later in this chapter.
• Age rating and rating certificates: This is where an app’s age rating can be identified. The page includes descriptions and guidelines for each rating category. Note that unless an app is specifically geared for kids, in most cases 12+ will be the age category to use. In addition to selecting a target age group, certain countries have mandatory and optional requirements for games and other apps to include certificates issued by certain ratings boards, which can be uploaded through this page.
• Cryptography: Apps must identify whether they use any kind of cryptography due to regulations concerning the export of technology that makes use of certain kinds of encryption. For certain uses of encryption within an app, an Export Commodity Classification Number (ECCN) must be provided.

Uploading an App Package

Once the pre-upload information has been completed for an app, an app package can be created and uploaded. Selecting Create App Packages from the Store menu or context menu will invoke the Create App Packages wizard which can be used to create the appxupload packages to be uploaded to the store. Upon completion of the creation of the package file, the final screen of this wizard will include a link to the folder where the file has been created, as well as the option to run the app through the Windows Application Certification Kit.

Windows Application Certification Kit

The tools installed for developing Windows Store apps include the Windows Application Certification Kit (ACK). Windows ACK is a tool that automates the process of testing several characteristics of Windows Store applications (among other application types). The tool will run the application multiple times while checking for functional and security issues. When the tool finishes, a report indicating any problems that must be addressed for the app to pass certification will be shown.

More information about using Windows ACK can be found at http://msdn.microsoft.com/en-us/library/windows/apps/hh694081.aspx. Microsoft has also published a white paper discussing the Windows ACK that can be downloaded from http://www.microsoft.com/en-us/download/details.aspx?id=27414.

32. A Certification Issue Identified in a Windows ACK Report

Post-Upload Content

Once the app package has been successfully uploaded, the last two pieces of information to be provided include the information that will be displayed to customers in the app’s Windows Store entry, and any notes that may help certification testers successfully navigate the app (e.g., test account usernames and passwords, descriptions of how to navigate to features whose access may not be obvious, etc.).

The application description information that can be provided includes:

• The app’s description text (mandatory).
• A listing of the app’s features (optional).
• Keywords that can be matched to help end users searching for an app (optional).
• Information about update contents (optional).
• The copyright and trademark information to display to the end user (mandatory).
• A description of any additional license terms related to the use of the application (optional).
• Application screenshots and related captions (at least one is mandatory). Note that the simulator discussed in previous chapters provides built-in facilities for taking app screenshots.
• Promotional images to be used if the app is selected to be featured in the Store (optional).
• An indication of any hardware recommendations (optional).
• A URL to a website related to the app (optional).
• An email address or URL that users can use to obtain app support (mandatory).
• A URL link to the app’s privacy policy text (mandatory if the app collects end users’ personal information or connects to online services).
• If the app includes in-app purchases through the Windows Store, a brief description of each in-app offer (mandatory if any offer entries have been provided).

The Certification Process

As each information gathering step is completed, its displayed status within the Dashboard will switch from Incomplete to Complete. Once all of the steps have been completed, the app can officially be submitted for certification and, if it passes the certification process, inclusion in the Windows Store.

The certification process is meant to be fairly transparent, and includes several steps:

• Pre-processing inspection: Ensures that the appropriate details needed to publish the app are in place, including ensuring that the developer account is in good order and that payout information has been set up correctly.
• Security tests: The app is examined for viruses and other malicious code.
• Technical compliance tests: The Windows Application Certification Kit is used to automatically test the app.
• Content compliance testing: The app’s content is examined by a human tester.
• Release date: If the app has indicated a particular release date is desired, this step will hide the app until the target release date arrives.
• Signing and publishing: The app is digitally signed to ensure it is not tampered with once approved and released, and then is published to the Windows Store.

In order to help provide transparency into the process, the Dashboard will indicate an app’s progress through each of these certification steps, along with information about how long each of these steps typically takes. Furthermore, whether or not an app fails certification, a certification report will be provided. The report can be used in case of failures to determine what went wrong, provide corrections, and resubmit the app.

The Windows Store app certification requirements revolve around a key set of tenets. In order to pass certification, Windows Store apps:

• Must provide value to the customer.
• May display ads, but must be more than just ads or websites-within-an-app.
• Must behave predictably.
• Must put the customer in control.
• Must be appropriate for a global audience.
• Must be easily identified and understood.

The specific guidance for how these criteria are to be met is communicated, but is expected to evolve. The latest version of these requirements along with revision history information can be found at http://msdn.microsoft.com/en-us/library/windows/apps/xaml/hh694083.aspx.

Including Trial Modes

Information gathered from Microsoft’s experiences with Windows Phone app sales provides interesting insights into the use of trial modes in apps.[1] At the time it was published, its analysis showed:

• Paid apps that offered trial modes were 70 times more likely to be downloaded than those that did not.
• The rate of conversion from a trial app to a paid app was nearly 10%.
• Apps that offered trial modes generated 10 times more revenue on average than paid apps that did not include trial modes.

As mentioned in the application pre-upload setting step, paid apps offered through the Windows Store can be configured to offer trial modes. WinRT APIs can be used within an app to determine if it is currently running in a trial mode, when the trial mode is set to expire, or if a trial mode has already expired.

The static CurrentApp class within the Windows.ApplicationModel.Store class is used to obtain information about an app’s current trial mode state. Among other functionality, this class offers members that can be used to retrieve information about an app’s listing in the Windows Store, the current state of the installed app’s license, and to request that a trial mode app be upgraded. The following code shows how the information related to trial mode for an application can be obtained.

The final aspect of interacting with trial mode apps is to provide the ability for a trial mode app to be upgraded to full functionality. This is provided by the RequestAppPurchaseAsync method on the CurrentApp class. Since this method needs to interact with the Windows Store, calling it requires the app to have access to an available Internet connection.

While there are circumstances that can result in this method throwing an exception, cancellation or other circumstances where the purchase is not completed can result in the method returning without error. As a result, it is important to either listen to the LicenseChanged event, or retrieve and inspect LicenseInformation at the conclusion of a call to RequestPurchaseAsync.

Debugging Trial Mode Applications

In order to develop, test, and debug applications that support trial modes, a mechanism is necessary to simulate the calls that Windows.ApplicationModel.Store.CurrentApp would otherwise make to the Windows Store. To help with this, the WinRT APIs include the Windows.ApplicationModel.Store.CurrentAppSimulator class. This class offers the same methods and properties as the CurrentApp class, plus one additional call. Because of this similarity, the CurrentAppSimulator class can be substituted for the CurrentApp class during development to validate the implementation of an app’s trial mode functionality.

In the most common use cases, the CurrentAppSimulator works by loading app information from a proxy XML file titled WindowsStoreProxy.xml that it expects to find inside the Microsoft\Windows Store\ApiData folder within the app’s local storage folder. The schema describing the values contained within the proxy file can be found in the MSDN documentation at http://msdn.microsoft.com/library/windows/apps/windows.applicationmodel.store.currentappsimulator.aspx.

The proxy file contains information describing basic app store information, including a collection of products offered for in-app purchase (this will be discussed in more detail later). It also includes the ability to configure the current state of the app’s license information that describes the trial status of an application and any purchased products, as well as settings that can be used to either specify HRESULT error codes that should be returned by CurrentAppSimulator method calls or instructions to bring up a dialog that allows those error codes to be set interactively.

It is important to note that updates made while an app is running occur in-memory and are not saved in the WindowsStoreProxy file, but rather exist only in memory. Relaunching the app will result in the file being read from disk again and any licensing changes that were previously made will have been lost.

Finally, any CurrentAppSimulator calls must be removed prior to submitting an app to the Windows Store. If an app includes simulator calls, it will fail certification. The following code makes use of the #if preprocessor directive to create a CurrentAppAccesor alias that allows swapping out the CurrentAppSimulator class for the CurrentApp class when the app is built in release mode:

In-App Purchases

In-app purchases allow end users to enhance an app by making purchases for discrete units of functionality above and beyond what is included in the basic application itself, such as additional game levels or perhaps seasonal content for a kids’ coloring app. Both free and paid applications can include in-app purchases, though it is important to note that an app that is not useful to end users without any in-app purchases will most likely fail certification. In-app purchases need to enhance application functionality in some way. While the terms for an app being included in the Windows Store do not restrict the mechanism used to safely and securely offer such purchases, the Windows Store does include a mechanism to conveniently integrate such functionality.

The Windows Store mechanism for in-app purchases uses the term "product" to indicate a discrete piece of functionality that is offered for in-app purchasing. Products are defined in the Advanced Features section of the application registration process, and must include:

• A product ID, which is an internal code used to identify the feature.
• A price, which can be any of the pricing values discussed previously for app pricing.
• A lifetime indicating how long the feature is active following the user’s purchase (includes Forever as an option).

A user-readable description of each product must also be provided, but this occurs later in the registration process when the application description information is being configured.

As with trial mode support, the in-app purchase information defined in the Windows Store registration process is paired with code designed to interact with it within the application.

The first task is to obtain the list of available in-app purchase items to be presented to users in whatever way is appropriate to the application. The list of defined packages can be obtained through the CurrentApp (and CurrentAppSimulator) object. The LoadListingInformationAsync method obtains information related to the app’s registration with the Windows Store, including the app’s name, description, age rating, current market, price, and product listings. The product listings include the Name, ProductId, and Price information for each registered package, which can then be shown to users.

The CurrentApp class includes a RequestProductPurchaseAsync method that functions much like the previously discussed RequestAppPurchaseAsync method, except that it allows the ID of the feature to be purchased to be specified. If the purchase is successful, the LicenseChanged event will be raised, and the CurrentApp LicenseInformation property will be updated.

When using the CurrentAppSimulator class, the XML includes the ability to define products within the application listing markup, as well as existing product purchases within the license information markup.

Adding Ads

Another means of realizing revenue from Windows Store apps is through the use of embedded ads. Like in-app purchases, the terms for an app being included in the Windows Store do not impose restrictions as to which specific ad display tool must be used, but the Microsoft Advertising SDK for Windows 8 provides a convenient mechanism for doing so that integrates with Microsoft’s pubCenter advertising platform. Regardless of the tool chosen, the basic certification requirements must always be met, especially those related to user privacy concerns.

Configuring pubCenter Content

To include Advertising SDK ads in a Windows 8 application, application and related "ad unit" information needs to be provided in pubCenter which can be accessed at https://pubcenter.microsoft.com. To access pubCenter, an account must be set up which will be used to manage application registrations as well as to configure payment information.

From a pubCenter account, the first step in preparing to provide advertising is to register an application. Registering an application merely requires identifying that it is a Windows 8 application and providing a name for the application so that pubCenter can generate a unique application ID. For each application, multiple ad units can be created. Ad units are uniquely associated with an application. Creating an ad unit requires defining a size and a category for the item to be presented to users. There are several ad sizes currently available for Windows Store apps; selecting the right one is dependent on the layout of the application and the space in which the ad is intended to fit. Ads should be placed where they can be seen by end users, but preferably in a way that does not interfere with users' ability to successfully use the app.

Ad units also require an ad category to be selected. The category (and potentially subcategory) value helps determine what ads will be shown in an effort to ensure that presented ads are relevant to the audience using the app. This is especially important because of the revenue model for advertisements. Ad revenue is realized based on a combination of impressions (the number of ads served to individual users' screens) and click-throughs (the number of times an ad is clicked). Ads that are relevant to the interests of the end user are more likely to be clicked, potentially increasing revenue.

The final configuration option for pubCenter is the ability to establish ad exclusions. Ad exclusions are used to grant the ability to exclude ads that link to certain URLs. The most obvious use for these is to prevent ads that link to competitors’ websites from being displayed within an application.

It is important to take note of both the Application ID and Demo Unit IDs that are created. They will be used when the advertising control is included in the Windows Store app.

Using the Advertising SDK

Before the ad control can be included in a Windows Store app, the Microsoft Advertising SDK for Windows 8 must first be downloaded and installed. Instructions for obtaining the SDK can be found at http://msdn.microsoft.com/en-us/library/hh506342.aspx. Also, including the ad control in a Windows 8 app requires the Internet (client) capability to be defined in the app’s manifest file.

The ad control can be included on a page manually or by dragging it from the toolbox in Visual Studio. Dragging it will add the appropriate project reference and XAML namespace declaration.

33. The Ad Control in the Visual Studio XAML Designer Toolbox

To manually include the control, the project will need a reference added to the Microsoft Advertising SDK for Windows 8 (Xaml) assembly. The page or control on which the ad control is being placed will need to include a namespace declaration for Microsoft.Advertising.WinRT.UI. The ad control can then be placed in the appropriate location and sized according to the dimensions of the ad unit being displayed.

Whether added manually or via drag-and-drop from the toolbox, the ad control ApplicationId and AdUnitId values need to be set based on the values noted previously in pubCenter.

There are several other settings available for the ad control—one such setting is the ability to provide latitude and longitude values to the ad control to ensure that the ads shown are contextual to the geographic region indicated by the coordinates. However, providing this piece of additional information will require the appropriate capability to be declared, users made aware that the information is being shared, and controls to allow users to opt out of providing such information.

Other Ways to Distribute Windows Store Apps

The primary focus of this chapter has related to distributing apps through the Windows Store. This is certainly the most common way these apps will be obtained by end users, and the only way to tap into the Windows Store mechanisms for trial modes and in-app purchases. However, there are several scenarios where this kind of deployment is not ideal, such as for an app outside of a development machine or for sharing line-of-business apps within an enterprise. For these and similar cases, there are some alternate deployment approaches available.

The first deployment option is through the use of developer licenses on target machines. This approach is most useful for situations where it is desirable to test an app on various non-developer machines. The app is secured with the self-signed certificate that is generated by Visual Studio, and is only able to run on machines that have a valid developer license available (discussed in Chapter 1). These developer licenses are only valid for a limited amount of time. The precise duration depends on whether they are obtained with a Microsoft account linked to a Windows Store account, though they can be renewed upon expiration. Apps running under the auspices of a developer account that has expired will appear with an X on their Start menu tile, indicating there is something wrong that prevents the app from running.

The easiest way to deploy an application using a developer license is to use the content emitted when Visual Studio creates an app package. The process for creating such a package was described earlier in this chapter, though if the intent is to create such a package without uploading it to the Windows Store, No can be selected in the question about building packages for upload in the first page of the Create App Packages wizard in order to skip the association steps.

A folder with a name of <App Package Name>_<Version>_<Processor Architecture>_Test will be added to the target directory where the package is created. This folder includes the content necessary to do a local app deployment, including a PowerShell script titled Add-AppDevPackage.ps1. This folder can be copied to the machine where the app is to be run, and the PowerShell script can be run to install the Windows Store app. The PowerShell script will also register the self-signed certificate and check to see if a developer license is available on that machine—if not, the user will be prompted to obtain one.

34. Contents of a Test Deployment Folder

The second deployment option is known as sideloading. In general terms, sideloading is often used to refer to the process of directly applying software to a device while bypassing a normal managed approach of doing so. However, for Windows Store apps, the term has been associated with one very specific mechanism for doing so. For an app to be able to be sideloaded on a device running Windows 8 or Windows RT, the following conditions must be met:

• The machine must be running Windows RT, Windows 8 Enterprise, Windows 8 Professional, or Windows Server 2012.
• If it is running Windows 8 Enterprise or Windows Sever 2012, the OS must be joined to an active directory domain that has the Allow all trusted applications to install group policy enabled.
• Alternatively, all Windows 8 Professional, Windows 8 Enterprise, or Windows Server 2012 systems that are not joined to an active directory domain may participate if they have a special sideloading product key applied and the Allow all trusted applications to install group policy setting has been enabled locally.
• Windows RT devices must have a special sideloading product key applied in order to participate.
• The application must be digitally signed with a certificate that is chained to a trusted root certificate on the target machine.

Sideloading is being positioned as a feature for enterprise operations to use to deploy applications in-house, and requires a certain amount of infrastructure and knowledge of Microsoft licensing and enterprise system management in order to be properly orchestrated. More specific guidance for the requirements described previously and how to manage sideloaded apps is available at http://technet.microsoft.com/en-us/library/hh852635.aspx

Recap

In this chapter, the basic concepts related to publishing an app to the Windows Store were presented, including the need to obtain a developer account and the process involved in submitting an app for certification. It also presented additional options available for realizing revenue from these apps, including offering trial modes, providing in-app purchases, and enabling ads in Windows Store apps. Finally, some additional options were discussed for how to deploy apps without involving the Windows Store.

This chapter concludes what has hopefully been a succinct yet useful discussion of many of the parts involved and available in the creation of Windows Store applications using XAML and C#. Certainly there is much more that can be covered, and hopefully the content that has been presented provides a solid foundation from which additional areas of this platform can be explored.

[1] Source: http://windowsteamblog.com/windows_phone/b/wpdev/archive/2011/03/08/an-update-on-windows-phone-marketplace-new-tips-policies-and-regional-access-program.aspx