But there was something missing...
feature.xmlAttempting to deploy the WSP threw:
Failed to find the XML file at location '12\Template\Features\IL.SharePoint.Workflows\feature.xml'
This TechNet page on InstallFeature clears up the exact cause being a missing feature.xml. It also cleared up that the 'root' of the WSP is equivalent to
12\Template\Features\ a location in the "12 hive".
Opening up the WSP, sure enough there was no sign of feature.xml, so it was time to head back into
WSPbuilder.exe -help where I found...
The default for the 12path is the current directory, here again, since we're not running from the project directory, the current directory isn't much good, so I needed to set the 12 path.
Setting the 12path to the location of the feature.xml got it included in the WSP, but the manifest.xml included it in the
RootFiles element. Based on our manually built WSP, we saw we needed it to be in the
After some searching I looked again at the before build image on the WSPBuilder CodePlex site. Turns out this is rather useful once you know what you're looking at. There you'll see the path
WSPDemo/12/Template/FEATURES/WSPDemo/; after seeing that, it dawned on me that I had actually read something about "putting the contents of your 12 hive into the project folder" - so that's what they meant.
So finally the files were included in the WSP in the right location:
-DeploymentTarget GACBecause of the way our solution is set up we need to target the GAC, we were getting:
<Assembly Location="IL.SharePoint.Workflows.dll" DeploymentTarget="WebApplication" />in the
manifest.xml. Changing the
DeploymentTargetfrom the default of
GACyielded the required:
<Assembly Location="IL.SharePoint.Workflows.dll" DeploymentTarget="GlobalAssemblyCache" />
The default for this is
True, with it on, the manifest file was spammed full of CAS information and trying to deploy gave the error:
The solution "IL.SharePoint.Workflows.wsp" needs to add Code Access Security policies. If you fully trust this solution, use the -allowCasPolicies parameter to deploy.True, using
-allowCasPoliciesdid remove the error, but adding
-BuildCAS Falsecleaned up the manifest file and removed the need for this switch to
Revised WSPBuilder command lineAll this meant the following amended
Execcommand in the tfsbuild.proj.
<Exec Command='"C:\Program Files\WSPTools\WSPBuilderExtensions\WSPBuilder"