SharePoint applications are made up of goodies such as custom web parts, lists, list event handlers, site definitions, site pages, application pages, and on and on. We package our SharePoint applications as features in order to maximize reusability and ease deployment. Then we add more deployment-ease by packaging our features and their resources as SharePoint solution (.wsp) files. The SharePoint Solution Installer provides the final touch by providing a nice wizard-based interface for solution deployment. Once our SharePoint administrators complete the SharePoint Solution Installer wizard (or use the equivalent STSADM commands), our features are “deployed”. All is good.
But wait…. What does it mean to “deploy” a feature in a solution package?
Simply put, the feature is installed to the *farm* at the scope specified for the feature in the feature.xml.
This means that the feature(s) within the solution will appear in the list of features available for activation in all cases of that scope. For example, if the feature is scoped to “web”, it will appear for activation in all sites for all site collections across all web applications on your farm.
The code which displays the list of features, for example, on the Site Features page, iterates over the SPFeatureDefinitions held in SPFarm.Local.FeatureDefinitions and filters out those which are not scoped to web, those which are hidden, and those which have AutoActivateInCentralAdmin flag set. In short, this means that a feature that you develop is available for activation across the entire farm.
This presents a problem in some environments where a feature may have been developed for use on one specific site in the farm. Site administrators for other sites in the farm may be confused when they see features in the list of site features which have no application to their site. One work around is to set the hidden attribute to True in the feature.xml. This will remove the feature from the Site Features list on all sites requiring use of STSADM to activate and deactivate the feature. Unfortunately, I have not found a cleaner solution.
Many though have wondered, “Why is it that I can *deploy* my feature to a specific web application while this blog post is telling me that the feature list is the same across all web applications in the farm?”
There are several ways to deploy your solution to a specific web application.
The STSADM command deploysolution accepts a URL
The SharePoint Solution Installer also allows you to choose a web application target for solution deployment.
Last, Operations-Solution Management in Central Administration will allow you to deploy and retract solutions from specific web applications.
So, what does it mean to deploy a solution to a specific web application?
The web application deployment target is used as the destination for the following application scope resources which may appear in your solution manifest. These are physical changes to files within your web application (IIS web site).
- ApplicationResourceFiles – Ex: MyFiles\My.resx. See the comment at the bottom of the solution manifest schema for some more detail.
- Assemblies (if the DeploymentTarget is set to WebApplication) – Ex: [web]\80\bin\MyAssembly.dll
- CodeAccessSecurity – Changes to <securitypolicy> section in [web]\web.config to point to a new custom policy file in \config
- DWPFiles – .webpart and .dwp files for custom web parts
- SafeControls – Additional entries in <SafeControls> section in [web]\web.config.
- [web] = your IIS web site folder, e.g., C:\inetpub\wwwroot\wss\VirtualDirectories\80
-  = your 12 Hive, e.g., C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\
The deployment methods listed above will not allow deployment to a web application if the solution package (.wsp) does not contain any resources scoped to a web application.
For example, STSADM –o deploysolution will give the following error in this case:
This solution contains no resources scoped for a Web Application and cannot be deployed to a particular Web application.
In summary, the deployment of a solution package to a specific web application pertains to resources included in the solution package and not to the installation of the feature itself. Interestingly, the feature is installed across the entire farm even though resources required for that feature may have only been deployed to select web applications. Activating a feature at a scope beneath a web application in which the solution package has not been deployed will result in missing resources exceptions for sure!
Hopefully this sheds some light on the subject of feature deployment and installation scope.