I got a question from a new user of the Magick framework, regarding deployment of solutions to a web application. Here’s the anonymized question:
I was reviewing the upgrade framework […] and noticed that everything is currently being deployed globally. Is there a reason that this framework needs to be global or can it be changed to be scoped to a particular web application?
Excellent question and one that confuses a lot of developers. This question isn’t just relevant to Magick either.
Short answer: There’s no difference.
Longer answer: Deploying a WSP to a particular web application does not, in fact, limit that solution, features, or components to that web application. In fact, it is quite the opposite; limiting a deployment to a certain web application creates problems with other web applications.
Features and solutions in SharePoint are always global and there’s no built-in way to modify that. You can activate web application scoped features on a specific web application, but that’s an entirely different matter and not applicable here.
What you actually do when you deploy to a certain web application is deploy any web application specific setting to IIS. For example, if you’re deploying an ASP.NET control, the web.config needs to be told to allow this control (through a SafeControl entry). You may also have any number of other IIS specific web.config changes.
Deploying a solution to a web application activates those settings in IIS and forces a reload of the web application. It does not in any way affect availability of those features or components in other web applications.
Because of the mandatory IIS recycle which leads to service interruption, Microsoft allowed for granular control over when and where a deployment happens so that the deployment could target off-peak hours or service windows for web applications that are critical or highly utilized.
The distinction is important because if you use those controls is web applications where you haven’t deployed the solution, IIS will not have the required changes in place and SharePoint will block those controls, giving you otherwise ‘weird’ error messages.
Frameworks like Magick or SPSIN will see every feature in the entire farm, regardless of deployment, when asking SharePoint for features available to a certain site or web. Users will see features from any installed solution, regardless of whether that solution is deployed to the web application. As such, you can have features that fail on activation simply because they haven’t been deployed to the web application and rely on IIS specific configurations like SafeControl entries.
Found this article valuable? Want to show your appreciation? Here are some options:
a) Click on the banners anywhere on the site to visit my blog's sponsors. They are all hand-picked and are selected based on providing great products and services to the SharePoint community.
b) Donate Bitcoins! I love Bitcoins, and you can donate if you'd like by clicking the button below.
c) Spread the word! Below, you should find links to sharing this article on your favorite social media sites. I'm an attention junkie, so sharing is caring in my book!