Several weeks ago, I converted our deployment process to use SharePoint solution packages instead of the batch scripts that we had been using in our Development environment. One of the issues that I discovered along the way is that SharePoint is rather finicky when it comes to running the stsadm.exe command to deploy your solution package.
I noted in a previous post that we have created a PublishingLayouts feature containing our custom master pages, images, and stylesheets — similar in structure to the feature provided in Microsoft Office SharePoint Server (MOSS) 2007. Creating the WSP file was quite straightforward, as was adding it to the solution store, using the following command:
However, as soon as I tried to deploy the solution using the following command:
I encountered the following error:
This solution contains no resources scoped for a Web application and cannot be deployed to a particular Web application.
I must have spent 30 minutes trying to figure out why this command did not work (because it worked just fine for other features that I had converted to deploy with WSPs). It turns out that I needed to omit the url parameter:
The reason why the PublishingLayouts solution would not deploy with the url parameter is because, unlike the other features, there was no assembly generated for the PublishingLayouts (since it was pure content).
I also encountered the following error when trying to deploy our custom Workflows feature:
Elements of type ‘Workflow’ are not supported at the ‘WebApplication’ scope. This feature could not be installed.
I found that I had to omit the url parameter for this solution as well.
I then decided to try omitting the url parameter when deploying all of the other solutions. Without the url parameter, I was able to deploy 7 of our 9 features. The remaining two produced the following error:
This solution contains resources scoped for a Web application and must be deployed to one or more Web applications.
For these two features, I had to specify the url parameter when invoking stsadm.exe, because the manifest.xml file for the WSP specifies a
<SafeControl> element. When deploying these two solutions, SharePoint needs to know which Web.config file to merge the
<SafeControl> elements into, and therefore the url parameter must be specified.
The bottom line is that if your solution specifies elements (a.k.a. “resources”) that need to be merged into a Web.config file (i.e. “for a Web application”) then you must specify the url parameter. If your solution does not have an assembly or if your solution contains workflows, then you cannot specify the url parameter.