How Visual Studio generates an app package manifest
When you build a project with Visual Studio, Visual Studio generates a package manifest (AppxManifest.xml), which contains information the system needs to deploy, display, or update a Universal Windows Platform (UWP) app.
There are two varieties of app package manifest files that you'll encounter if developing an app with Visual Studio
This is an XML style file that developers use to configure the details of an app, such as publisher information, logos, processor architectures, etc. This is an easily configurable, temporary version of the app package manifest used during app development.
This file is generated by the Visual Studio build process and is based on the information in the Package.appxmanifest file. This is the final version of the app package manifest used with published and sideloaded apps. If any updates are made to the Package.appxmanifest file, you must rebuild the project to see the updates in the AppxManifest.xml file.
For an overview of the packaging process, see Package a UWP app with Visual Studio.
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.
If these sections don’t mention the field that you’re looking for, it’s generated from either data that may have been configured separately or a default value from the manifest schema.
Generating the manifest content
Visual Studio populates the fields in the following tables when it generates the AppxManifest.xml file for the app package.
Identity section of the app manifest contains the following fields.
|Name||The name of the package, which is populated differently in the following scenarios:
|Publisher||The name of the publisher. This name gets populated differently in the following scenarios:
|Version||The version of the app being built. This is typically incremented each time the app is has been modified and packaged. To ensure that the
|ProcessorArchitecture||A value that's generated based on the build configuration that you specified for the project. If project references or file references in the project target a different specific architecture 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.|
Here's an example of the
Identity output XML:
<Identity Name="Microsoft.UWPAppExample" Publisher="CN=Microsoft Corporation" Version="126.96.36.199" ProcessorArchitecture="x86" />
Properties section of the app manifest contains the fields in the following table.
|PublisherDisplayName||This string is populated differently in the following scenarios:
|DisplayName||This string gets populated differently in the following scenarios:
|Logo||A Visual Studio template will use
Here's an example of the
Properties output XML:
<Properties> <DisplayName>UWP App Example</DisplayName> <PublisherDisplayName>Microsoft Corporation</PublisherDisplayName> <Logo>Assets\StoreLogo.png</Logo> </Properties>
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.
|Id||This string gets populated differently in the following scenarios:
|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.|
|EntryPoint||This value is based on the generated
<Applications> <Application Id="App" Executable="UWPAppExample.exe" EntryPoint="UWPAppExample.App"> <!-- Other elements configured within the Application, such as Extensions, VisualElements, etc. --> </Applications>
PackageDependency section contains all the Windows component library dependencies for this package. For example, if your project has a reference to WinJS, Visual Studio retrieves the package identity information of the dependencies when the manifest is generated. Visual Studio then populates this section with the
MinVersion fields for each dependent package.
Windows Runtime registration extensions
You can implement Windows Runtime components for your apps, but you'll need to 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
Extension 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:
- 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>
For more information on this topic, see Windows Runtime components.
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.
TargetDeviceFamily section contains the following fields:
These elements are populated from MSBuild properties.