Corey Roth [MVP]

There are a ton of tools out there to create SharePoint solution packages (.wsp files) for you, but it is still a good idea to know what those tools are creating for you exactly.  Sometimes, things don't always work right, and you may need to customize or tweak your manifest file.  If you are new to SharePoint development, the Manifest.xml file is used during the deployment of a .wsp solution package.  It tells SharePoint what files to copy, what features to install, where to put your binaries, adds SafeControl entries, as well as set code access security.  The file seems pretty straight forward but there are a lot of ways to mess it up.  As I pointed out in the past, do not put any comments in this file.  It will cause all kinds of FAIL. 

I'll start by go over the key elements of this file and point out some things you need to know about each one.  If you create any of these main elements, note, that they will always require some kind of child element, otherwise the file won't validate.  The first element we will talk about is FeatureManifests.  This name as it sounds is used to deploy features.  Your solution will install features but not activate them for you.  You can list multiple features to install here using the FeatureManifest element.  It's Location attribute specifies the path to the feature (inside the DDF file).  What that means is the path specified to your feature.xml file will match whatever you have listed as the destination in your DDF file.  We can talk about DDF files again another day if necessary.

The TemplateFiles element is used to copy out any additional files to the SharePoint server.  These could be .webpart files, user controls, other XML files, application pages, master pages, etc.  SharePoint will not copy any file that is not listed here (except for binaries and feature.xml and related files).  Again, you can specify multiple TemplateFile child elements to copy multiple files.  Part of what makes this file tricky is the paths.  Some are relative, some require you to specify something inside the 12 hive.  It takes some getting used to.  In this case, if you are copying additional files into a feature folder for a web part, you would specify something like FEATURES\MyFeature\mywebpart.webpart.

The Assemblies element specifies which binaries will be deployed to SharePoint and where.  You can copy multiple assemblies out at a time with a feature by specifying more than one Assembly element.  The Assembly element has a Location attribute which typically just contains the DLL name (again dependent on where the DLL is copied in your DDF file).  It also contains a DepoymentTarget attribute which specifies wether to copy it to the GAC (GlobalAssemblyCache) or the bin folder (WebApplication).  It also contains a SafeControls element with the same syntax of what is used in the web.config. 

One thing to note here is that if you do not specify at least one assembly with a SafeControl element, SharePoint will decide that your solution does not contain a Web Application Resource and therefore will not deploy it when you specify a URL with stsadm.  So, I typically include this line even if I don't have any controls or web parts in my solution.  You will get an error like the one below.

This solution contains no resources scoped for a Web application and cannot be deployed to a particular Web application.

The last element, I am will talk about is CodeAccessSecurity.  This of course is the most complex one.  I have posted on this topic in the past and don't forget, I will be speaking about it next month.  The post I have on it covers it in more detail that I will cover today.  The one thing, I will remind you of is that it is ok to specify multiple assemblies. 

I haven't talked about the root element yet. It's pretty simple.  Just remember the SolutionId needs to be unique.  The ResetWebServer attribute can be set to false if you don't want it to reset IIS on deployment.

Anyhow, hopefully this will help someone out the next time they are looking at a manfiest.xml file.