What I learned about being a Windows Phone 7 Developer – Issue 2– Application Manifest
Overview
This is the second installment in an ongoing series of my experiences developing for Windows Phone 7. The first issue included my background, a general overview of my experience developing for Windows Phone 7 and what type of revenue my own app has seen. If you missed it you can read it here.
Windows Phone Application Manifest
The Application Manifest file for Windows Phone is called WMAppManifest.xml and it contains several pieces of important information. This file is part of the Marketplace Certification process that understands your application’s capabilities. These capabilities get listed in your application’s description page for users both on the phone and in the Zune Marketplace software. This file is generated automatically every time you compile and for most developers you won’t need to touch it. There are a few instances like application capabilities however that I want to cover.
Capabilities
The default project’s included capabilities are numerous and I highly recommend removing whatever your application is currently not using instead of keeping it in for future use. Having a drawing application for example that asks for microphone access might put doubt into your users mind. Other capabilities such as location require you to implement user notifications before passing certification. The goal should be to get this section as small as possible with only what you currently need.
For example the manifest file for DoodlePad looks like this:
<Capabilities>
<Capability Name="ID_CAP_MEDIALIB" />
</Capabilities>
Which has the following capabilities description on Marketplace:
You would expect a drawing application to have access to your media library. The ability to load backgrounds and save out your drawings is a useful feature. You will however see some differences when it comes to free applications.
For example the manifest file for DoodlePad Free looks something like this:
<Capabilities>
<Capability Name="ID_CAP_IDENTITY_DEVICE"/>
<Capability Name="ID_CAP_IDENTITY_USER"/>
<Capability Name="ID_CAP_LOCATION"/>
<Capability Name="ID_CAP_MEDIALIB"/>
<Capability Name="ID_CAP_NETWORKING"/>
<Capability Name="ID_CAP_WEBBROWSERCOMPONENT"/>
</Capabilities>
Which has the following capabilities description on Marketplace:
Notice that even though both versions of my application do the same thing and run off the same code base they are using different capabilities of the phone. This winds up actually being due to a requirement of the PubCenter Ad System that I will go into more when I cover creating Ad based apps. For now I just want to point out the importance of what you put here in the phone capabilities and how that will end up being verified during certification and ultimately displayed to your users. So really be certain of what you are putting into the capabilities field. As a user of free Windows Phone 7 applications this is also something that you will be used to seeing in the application descriptions.
So what should you include for your own application? Fortunately for us developers Microsoft provides a free tool called the Capability Detection Tool that helps with that. Running this tool will give you details on what you need to edit in the capabilities section of your manifest file. The only thing I have seen it hiccup on is with Ads. I needed to ad those fields myself when using the Pubcenter Ad Control. This will most likely be fixed in a future version but something you should be aware of.
Genre
You may have seen blog posts during the beta tools days talking about not being able to display XNA games after exiting. That issue was fixed at RTM and should no longer be a problem. This has to do with the Genre being listed in the manifest file as App.Games instead of App.Normal. If you have Windows Phone 7 device though for testing you can use the same trick in reverse.
By editing the App.Normal to App.Games and then deploying to your phone you will see what your application looks like in the Games Hub! This is a great way to ensure your game icons displays correctly when running inside Game Hub at 173x173 pixels.
Version
I have seen some confusion on what exactly uses version number so I wanted to talk about it here Generally the version number you can leave at 1.0.0.0 it will not be the version of your application that gets displayed on the Marketplace. That version number is always the one that you entered manually during your application’s submission. The certification process will add the correct version number back into the manifest file during processing without you needing to do anything.
What I did during Doodlepad’s development was to keep a version number in App.xaml that the rest of my code references. This way I only needed to change it in one place when pushing out an update. I have also gotten into the habit of keeping all versions of the application I have submitted through the AppHub. I am talking about the actual xap file and assuming all of you are already using some type of source control for your code right? <wink> So I typically zip up the submitted xap that was uploaded to the AppHub along with its thumbnail images and application description. I then name the zipfile a combination of the appname, version and date it gets published to the marketplace. This goes into source control under an AppHub releases folder. This has already saved me some headaches when I wanted to go back and see how much faster a newer version with re-written controls ran than the old. Sure you could recompile from source but there is nothing like the security of knowing the xap file you are testing was the same exact one that you submitted to AppHub.
Conclusion
Hopefully my own experiences using the WMAppManifest file will help steer you clear of any issues. Always make sure you run the capabilities detection tool and keep those capabilities as small as possible. If you have had an UnAuthorizedAccess Exception from the Ad Control while debugging this may very well fix your issue.