Windows 8.1 Store apps: Contents of the package manifest

 

Applies to Windows and Windows Phone

When you build an app project, Visual Studio generates a package manifest, which contains information that’s required to register the app with the Store. This topic describes the contents of the 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 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:

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 Manage the certificates that Visual Studio uses to sign your app

 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:

- 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.3.0.

See Also

Packaging Universal Windows apps