Application Manifest File for Windows Phone

The application manifest file is generated in Visual Studio, and you should not edit the file manually. For most scenarios, the manifest file should be modified only by changing values in the project properties page in Visual Studio. Some of the values in the manifest file will be updated automatically after you submit your application to the Windows Phone Marketplace. Examples include the Author, Publisher, and ProductID attributes, and the CAPABILITIES element.

Caution:
Your application may become unstable or unusable through file modification.

One scenario in which you should edit the manifest file is when you use the Windows Phone Capability Detection Tool to determine the capabilities used by your application. For more information, see How to: Determine Application Capabilities.

Back to Top

The following is an example of a manifest file for a Windows Phone application.

<?xml version="1.0" encoding="utf-8"?>

<Deployment xmlns="http://schemas.microsoft.com/windowsphone/2009/deployment" AppPlatformVersion="7.1">

  <App xmlns="" ProductID="{GUID}" Title="[Project Name]" RuntimeType="Silverlight" Version="1.0.0.0" Genre="apps.normal"  Author="[Project Name] author" Description="Sample description" Publisher="[Project Name]">
  
    <IconPath IsRelative="true" IsResource="false">ApplicationIcon.jpg</IconPath>

    <Capabilities>
      <Capability Name="ID_CAP_APPOINTMENTS"/>
      <Capability Name="ID_CAP_CAMERA"/>
      <Capability Name="ID_CAP_CONTACTS"/>
      <Capability Name="ID_CAP_GAMERSERVICES"/>
      <Capability Name="ID_CAP_IDENTITY_DEVICE"/>
      <Capability Name="ID_CAP_IDENTITY_USER"/>
      <Capability Name="ID_CAP_ISV_CAMERA"/>
      <Capability Name="ID_CAP_LOCATION"/>
      <Capability Name="ID_CAP_MEDIALIB"/>
      <Capability Name="ID_CAP_MICROPHONE"/>
      <Capability Name="ID_CAP_NETWORKING"/>
      <Capability Name="ID_CAP_PHONEDIALER"/>
      <Capability Name="ID_CAP_PUSH_NOTIFICATION"/>
      <Capability Name="ID_CAP_SENSORS"/>
      <Capability Name="ID_CAP_WEBBROWSERCOMPONENT"/>
      <Capability Name="ID_HW_FRONTCAMERA"/>
    </Capabilities>

    <Tasks>
      <DefaultTask  Name ="_default" NavigationPage="MainPage.xaml"/>

      <ExtendedTask Name="" NavigationPage="" >
        <BackgroundServiceAgent  Name="" Source="" Specifier="" Type=""/>
      </ExtendedTask>
    </Tasks>

    <Tokens>
      <PrimaryToken TokenID="[Project Name]Token" TaskName="_default">
        <TemplateType5>
          <BackgroundImageURI IsRelative="true" IsResource="false">Background.jpg</BackgroundImageURI>
          <Count>0</Count>
          <Title>[Project Name]</Title>
        </TemplateType5>
      </PrimaryToken>
    </Tokens>

    <Extensions>
      <Extension ConsumerID="" ExtensionName="" ExtraFile="" TaskID="" />
    </Extensions>

  </App>
</Deployment>

Note:
The CAPABILITIES element in the preceding example may not match the one in the manifest file of your application. For more information, see The CAPABILITIES Element later in this topic.

Back to Top

The DEPLOYMENT element is the root element. This provides application and localization information in the manifest file when deploying a Windows Phone application.

Back to Top

The APP element is a child of the DEPLOYMENT element. It supplies information such as the product ID, version, and type of application. The following table defines the attributes of the APP element.

Back to Top

The ICONPATH element is a child of the APP element. It provides the location of the application icon that is visible in the application list. The default image is ApplicationIcon.png for Silverlight projects and PhoneGameThumb.png for XNA Framework games. The attributes are for internal use only.

Back to Top

The CAPABILITIES element is a child of the APP element. Windows Phone provides a capabilities-driven security model where a user must opt-in to certain functionality within the application. Some examples include using network-based services where a user could incur additional roaming charges if the use of the services was not disclosed in the application, or the use of push notifications that can also produce roaming charges. The primary goals of this capability model are to:

• Ensure proper disclosure – Users must be notified if an application’s functionality poses security risks. They must opt-in to allow the functionality to be activated.

• Decrease the attack surface – Capabilities are used to create a security chamber in which the application executes. This chamber is created once at install time and used from then on for the application. The following tables highlight the currently supported capabilities and their descriptions.

When you are developing your application, if you do not need to use a specific capability, you can remove the entry. However, if you do not use a capability when needed, you receive an UnauthorizedAccessException error with an “Access denied” message when you attempt to use the functionality in the application. For more information, see How to: Determine Application Capabilities.

The CAPABILITY Element

The REQUIREMENTS element is a child of the APP element and should immediately follow the CAPABILITIES element. Beginning in Windows Phone SDK 7.1.1 Update, use the REQUIREMENTS element to indicate if the application requires certain hardware. For example, if the application will not run on a 256-MB device, you should specify it in this section. The primary goal of this element is to block users from purchasing or installing applications that will not run on their device.

A REQUIREMENTS element is not required in your manifest file if the application can run on 256-MB devices and there are no other special hardware requirements

The REQUIREMENT Element

The REQUIREMENT element is a child of the REQUIREMENTS element. The REQUIREMENT element has one attribute, name, which accepts a string value. The following table lists the possible values of the name attribute.

Value	Description
ID_REQ_MEMORY_90	Indicates the application requires more than 90 MB of memory and is not suited for a 256-MB device. For more information see, Developing for 256-MB Devices. Note: Including this requirement in the application manifest will not prevent the application from being deployed from Visual Studio to the 256-MB Windows Phone Emulator or to a tethered 256-MB device.

The TASKS element is a child of the APP element. This element is for internal use only.

The EXTENDEDTASKS Element

The BACKGROUNDSERVICEAGENT Element

The TOKENS element is a child of the APP element. Each application has a Tile that the user can pin to the Start screen. The following sections provide the names and describe the elements and attributes for Tiles in the manifest file. For more information, see Tiles Overview for Windows Phone.

The PRIMARYTOKEN element

The PRIMARYTOKEN element is a child of the TOKENS element. It describes the Tile that is associated with an application.

Attribute	Type	Description
TokenID	String	The name of the Tile. The default value is the project name. Caution: If you change the TokenID of your primary token, it should not match the TokenID of any of your secondary Tiles. In that case, users may not be able to install updates to the application.
TaskName	String	The name of the task that the Tile invokes when the user taps it. The default value is _default.

The TEMPLATETYPE5 Element

The EXTENSIONS element is a child of the APP element. This element is used to specify the extensions that your application supports. For more information, see Search Extensibility Overview for Windows Phone.

The EXTENSION Element

Other Resources