[This documentation is preliminary and is subject to change.]

As a developer, you don't write routines to install or uninstall your Metro style app. Instead, you package your app and submit it to the Windows Store. Users acquire your app from the Windows Store as an app package. Windows uses information in an app package to install the app on a per-user basis, and ensure that all traces of the app are gone from the device after all users who installed the app uninstall it.

An app package is a container based on the Open Packing Conventions (OPC) standard. OPC defines a structured means to store data and resources for the app using a standard ZIP file.

Contents of an app package

Each package consists of the files that constitute an app, along with a package manifest file that describes the app to Windows. Each app can also have images, media files, web pages, and dynamic-link libraries (DLL).

Although each package can contain one or more apps, packages that contain multiple apps won't pass the Windows Store certification process.

After a package is installed on a disk, it is represented as a directory. For example:

AppXManifest.xml

img\tile.png

main.htm

program.js

style.css

Package manifest

Each package includes a package manifest that describes an app to Windows. For info about authoring the manifest in Visual Studio, see Updating the app manifest. For info about authoring the manifest in a text editor, see How to create a package manifest manually.

This is the key content contained in a package manifest file:

• Package identity
• Package properties
• Capabilities
• Extensions
• Visual elements

Package identity

Each package is defined by a globally unique identifier known as the package identity. The package identity consists of 5 tuples:

name

The name of the package. For example, "myCompany.mySuite.myApp".

version

The version number of the package. For example, "1.0.0.0".

publisher

The publisher specified in the subject field of the signing certificate used to sign the package. This is a string that contains a comma-delimited X.500 distinguished name. To find the name, run Certmgr.msc, open your signing certificate, click the Details tab, and double-click the Subject field. Alternatively, run Certutil.exe to retrieve the subject name.

processor architecture

Optional. The architecture of the package. This value can be "x86", "x64", "arm", or "neutral".

resource ID

Optional. The type of UI resources in the package. This is a publisher-specified string.

If you are creating the package manually, see the Identity element.

Package properties

Each package is described through its package properties, such as these:

DisplayName

The friendly name of the app.

PublisherDisplayName

The friendly name of the app publisher.

Description

The text that describes the app on its tile.

Logo

The image that represents the app on its tile.

In Visual Studio, use the Application UI tab to set these properties. If you are creating the package manually, see the Properties element.

Capabilities

An app can require access to protected system resources or user data. If you determine that your app requires this type of access, indicate this using the package manifest. In Visual Studio, see the Capabilities tab. If you are creating the package manually, see the Capabilities element.

For more info, see App capability declarations.

Extensions

An app can interact with the system or other apps through extensibility points called extensions. Use the package manifest to declare extensions. For example, an app can declare that it handles files with certain file extensions, or that it uses a particular dynamic-link library. In Visual Studio, see the Declarations tab. If you are creating the package manually, see the Extensions element.

For more info, see App contracts and extensions.

Visual elements

Each app has certain visual aspects, such as the default tile, logo images, background color, and splash screen. In Visual Studio, see the Application UI tab. If you are creating the package manually, see the VisualElements element.

Here's an example entry in the manifest.

<Applications>
  <Application Id="MyCompany.MySuite.MyApp" StartPage="default.html">
    <VisualElements DisplayName="My App" Description="A useful description." 
         Logo="images\Logo.png" SmallLogo="images\SmallLogo.png" 
         ForegroundText="light" BackgroundColor="#00b2f0" ToastCapable="true">
      <DefaultTile ShortName="MyApp" ShowName="allLogos" WideLogo="images\WideLogo.png" />
      <SplashScreen Image="images\SplashScreen.png" BackgroundColor="white" />
    </VisualElements>
  </Application>
</Applications>

App packaging

There are several tools and APIs that can be used to package and deploy your app. These tools and APIs produce the same results, so you can choose any of them, and you don't need to use the same tool or API for each step in the process. To learn how to package your app, see these topics:

• Packaging your app using Visual Studio
• App packager (MakeAppx.exe)
• How to create a package (packaging API)

All packages must be signed with a trusted signature. This enables Windows to confirm the identity of the signer and verify that the contents of the package haven't been tampered with. Windows won't deploy an unsigned package. To learn how to sign a package using Visual Studio, see Signing a package. To learn how to sign a package using Signtool, see To sign the package.

After your app is packaged, you can upload it to the Windows Store. Note that the Windows Store is not open for submissions for Windows 8 Release Preview.

App install

Users discover and purchase apps from the Windows Store. After users purchase an app, they receive a license that enables them to install the app. (You can install an unpackaged apps as you develop them if you have a developer license.)

Windows installs and registers the app for the user who purchased it. There's no need for elevation to install the app, and there are no custom actions during the install. Everything Windows needs to install the app is contained in the package, so the user won't be prompted for additional information.

Apps are installed under the %ProgramFiles%\WindowsApps directory. This directory is secured so that users can't easily access it.

App update

Windows Update can notify your customers that you have released an updated version of your app. Users must choose to install any updated versions of your app that you make available.

App removal

When a user uninstalls your app, Windows removes the app only for that user. Application data for the app is also removed from the computer on a per-user basis. If multiple users have installed your app, all users must uninstall the app before it is removed from the computer.

Packaging and deployment programming interfaces

Windows Runtime

• Windows.ApplicationModel.Package class
• Windows.Management.Core namespace
• Windows.Management.Deployment namespace

Win32/COM

• App packaging API
• Package management API

Build date: 5/22/2012