4 out of 11 rated this helpful - Rate this topic

Generating the package manifest (Windows Store apps)

When you build an app, Visual Studio generates a package manifest, which contains information that’s required to register the app with Windows 8. For an overview of the packaging process, see Packaging your Windows Store app using Visual Studio 2012.

Validating the app manifest

Before you can publish your app, you must fix any errors that cause any of the Visual Studio validation checks to fail. When Visual Studio generates the manifest, Visual Studio validates your app in the following ways:

Syntactic validation. Visual Studio confirms whether all data in the app manifest conforms to the app manifest schema.
Semantic validation. Visual Studio provides guidance on expected data, based on the context of the information.

Generating the manifest content

Visual Studio populates the fields in the following tables when it generates the manifest for the app package:

Note
If these sections don’t mention the field that you’re looking for, it’s generated from either data that you configured separately or a default value from the manifest schema.

Identity

The Identity section of the app manifest contains the following fields.

Field	Description
Name	The name of the package, which gets populated differently in the following scenarios: By default, the value of this field is a generated GUID. If you associate the app with the Windows Store or you invoke the Create App Package command and then sign in with a developer account, the value of this field is retrieved from the associated app on the Store. If you invoke the Create App Package command but don’t sign into a Microsoft developer account, the value of this field is taken from the source manifest.
ProcessorArchitecture	A value that’s generated based on the build configuration that you specified for the project. The following table summarizes the mapping between the Platform values in Configuration Manager and the value that’s inserted in the app manifest: Platform architecture in Configuration Manager Corresponding value in the app manifest x86 or Win32 x86 x64 x64 Any CPU Neutral ARM ARM If project references or file references in the project target a different specific architecture (that is, not a Neutral component) than the app package, a build error is thrown, and you must change the target architecture of the app package to work for all references.
Publisher	The name of the publisher. This name gets populated differently in the following scenarios: By default, the value of this field is your user name. If you associate the app with the Store or you invoke the Create App Package command and then sign in with your developer account, the value of this field is the Publisher string that’s associated with that account. If you invoke the Create App Package command but don't sign in with a developer account, the value of this field matches the subject field of the test certificate with which you signed the app package. For more information, see Signing an app package (Windows Store apps) Note Visual Studio supports only the common name (CN) form for publisher and will add the prefix CN= to the name in the manifest.

Field

Description

Name

The name of the package, which gets populated differently in the following scenarios:

By default, the value of this field is a generated GUID.
If you associate the app with the Windows Store or you invoke the Create App Package command and then sign in with a developer account, the value of this field is retrieved from the associated app on the Store.
If you invoke the Create App Package command but don’t sign into a Microsoft developer account, the value of this field is taken from the source manifest.

ProcessorArchitecture

A value that’s generated based on the build configuration that you specified for the project. The following table summarizes the mapping between the Platform values in Configuration Manager and the value that’s inserted in the app manifest:

Platform architecture in Configuration Manager Corresponding value in the app manifest

x86 or Win32 x86

x64 x64

Any CPU Neutral

ARM ARM

If project references or file references in the project target a different specific architecture (that is, not a Neutral component) than the app package, a build error is thrown, and you must change the target architecture of the app package to work for all references.

Publisher

The name of the publisher. This name gets populated differently in the following scenarios:

By default, the value of this field is your user name.
If you associate the app with the Store or you invoke the Create App Package command and then sign in with your developer account, the value of this field is the Publisher string that’s associated with that account.
If you invoke the Create App Package command but don't sign in with a developer account, the value of this field matches the subject field of the test certificate with which you signed the app package. For more information, see Signing an app package (Windows Store apps)

Note

Visual Studio supports only the common name (CN) form for publisher and will add the prefix CN= to the name in the manifest.

Here's an example of the output XML:

<Identity
    Name="Microsoft.CoolWindowsStoreApp"
ProcessorArchitecture="x86"
Publisher="CN=Microsoft Corporation"
/>

Properties

The Properties section of the app manifest contains the fields in the following table.

Field	Description
PublisherDisplayName	This string gets populated differently in the following scenarios: By default, the value of this field is your user name. If you associate the app with the Store or you invoke the Create App Package command and sign in with a developer account, the value of this field matches the PublisherDisplayName string that’s associated with your developer account. If you invoke the Create App Package command but don't sign in with a developer account, the value of this field is your user name, unless you specify otherwise.
DisplayName	This string gets populated differently in the following scenarios: By default, the value of this field is the name of the project. If you associate the app with the Store or you invoke the Create App Package command and sign in with a developer account, the value of this field is populated according to the following rules: If you specify this value in the source manifest and the value starts with @ (which indicates that you want to localize this value), the value of this field will match what you specified. If the selected app has only one name, the value will be that name. If the selected app has multiple names but the source manifest isn’t localized: If the display name in the source manifest matches any name that’s reserved, the value is set to that name. Otherwise, the value is set to the first reserved name. If you invoke the Create App Package command but don't sign in with a developer account, the value of this field is taken from the source manifest.

Field

Description

PublisherDisplayName

This string gets populated differently in the following scenarios:

By default, the value of this field is your user name.
If you associate the app with the Store or you invoke the Create App Package command and sign in with a developer account, the value of this field matches the PublisherDisplayName string that’s associated with your developer account.
If you invoke the Create App Package command but don't sign in with a developer account, the value of this field is your user name, unless you specify otherwise.

DisplayName

This string gets populated differently in the following scenarios:

By default, the value of this field is the name of the project.
If you associate the app with the Store or you invoke the Create App Package command and sign in with a developer account, the value of this field is populated according to the following rules:
- If you specify this value in the source manifest and the value starts with @ (which indicates that you want to localize this value), the value of this field will match what you specified.
- If the selected app has only one name, the value will be that name.
- If the selected app has multiple names but the source manifest isn’t localized:
  - If the display name in the source manifest matches any name that’s reserved, the value is set to that name.
  - Otherwise, the value is set to the first reserved name.
If you invoke the Create App Package command but don't sign in with a developer account, the value of this field is taken from the source manifest.

Application

A app manifest can contain multiple <application> elements, each of which has a display name that appears on the tile in the client. The Application section of the app manifest contains the fields in the following table.

Field

Description

DisplayName

This string gets populated differently in the following scenarios:

By default, the value of this field is the name of the project.
If you associate the app with the Store or you invoke the Create App Package command and sign in with a developer account, the value of this field is the app name for the selected app if the /Properties[@DisplayName] and the /Applications/Application[@DisplayName] in the source manifest match. Otherwise, the value remains the same as in the source manifest.
If you invoke the Create App Package command but don't sign in with a developer account, the value of this field is the same as in the source manifest.

Executable

The value of this field is the output name of the project assembly. The Executable token $targetnametoken$.exe that's used in the source manifest file (package.appxmanifest) is replaced with the actual file name when the manifest is built.

PackageDependencies

The PackageDependencies section contains all the Windows component library dependencies for this package. For example, if your project has a reference to the WinJS, Visual Studio retrieves the package identity information of the dependencies when the manifest is generated. Visual Studio then populates this section with the Name and MinVersion fields for each dependent package.

Windows RunTime Registration Extensions

You can implement Windows RunTime components for your apps, but you must register those components with the operating system for them to run correctly. To register a Windows RunTime component, you must put the registration information in the WinMD files and in the app manifest. If a project implements a Windows RunTime component, the build output of the project will contain a WinMD file. Visual Studio extracts the Windows RunTime registration information from the WinMD file and generates the appropriate Extensions elements in the app manifest.

The system supports two forms of servers: .dll servers (in-process) and .exe servers (out-of-process). These servers require similar but different registration information that must be copied into the app manifest. Visual Studio supports generating manifest only for .dll servers, and the DLLServer extension is required to register .dll servers. The following values in the app manifest are taken from the WinMD files to construct the DLLServer Extension:

DllPath
ActivatableClassId
ThreadingModel
ActivatableClass (ActivatableClassId attribute)

Here's an example of the output XML:

<extension category=”Microsoft.Windows.ActivatableClass”>
    <dllServer>
        <dllPath>Fabrikam.dll</dllPath>
        <activatableClass activatableClassId="Fabrikam.MyClass" threadingModel="sta" />
    </dllServer>
</extension>

Resources

The Resources section contains an entry for each language that the application supports. You must have at least one Resource language specified in the app manifest. Visual Studio automatically generates the list of supported languages based on the localization information in the project. The Resource Language token "x-generate" that's used in the source manifest file (package.appxmanifest) is replaced with the actual language code when the manifest is built. Here's an example of the output XML:

<Resources>
<Resource Language=”en-us”>
<Resource Language=”fr-fr”>
</Resources>

The first entry in the list is the default language for the app.

Prerequisites

The Prerequisites section contains the following fields:

OSMinVersion
OSMaxVersionTested

Both elements are populated from MSBuild properties (AppxOSMinVersion and AppxOSMaxVersionTested, respectively). The default value for both elements is 6.2.1.

Concepts

Packaging your Windows Store app using Visual Studio 2012