Question on Deploying Solutions to a Web Application in SharePoint

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!

Pin It

Magick Upgrading in SharePoint

Key to the Magick framework for SharePoint solutions is the concept of upgrades.

In previous articles, I’ve outlined how Magick supports and encourages certain principles that are important to building maintainable and upgradable SharePoint solutions. Now it is time to get a bit technical and look at how this actually happens.

There’s a bit of theory still, though.

Magick Solution Structure

Everything in Magick is by convention only, except for one single requirement.

By “convention only”, I mean that you are free to design your solutions in any way you like. You can use any development tool you like (WSPBuilder, VSTools for SP, STSDev, or Notepad), you can follow any patterns you like, and you can combine all of these in any way you like.

There’s one single requirement, though, and that is that you tag your features with a certain custom property.

Features in SharePoint support custom properties just fine, and they’re simply ignored if not used, so this requirement is a very basic and non-intrusive requirement.

The reason for this requirement is that these custom properties are how Magick determines what to do with those solutions.

There are two custom properties you need to add to your features. The first property, called UpgradeSolutionID tells Magick which upgrade path you want to take. The second property, called UpgradePriority, is a number that tells Magick in which order to run the upgrades.

An example feature may look like this:

<Feature xmlns=””
Title=”My Magick feature”
Description=”Some description”
<Property Key=”UpgradePriority” Value=”15″ />
<Property Key=”UpgradeSolutionId” Value=”Magick” />

I’ve highlighted the custom properties section, which you need to add to any features that you wish to add to Magick.

That’s it! If you learn how to add those custom properties (or simply copy them from here) you’re done. There’s no need to learn anything else, really, and there’s no need to make any other changes to any features.

How Magick Really Works

You may be surprised by the simplicity of the changes required to create Magick features, but don’t be deceived by this simplicity. Behind these properties lies an awesome power with virtually no side effects, and you can build some pretty complex multi-path upgrade scenarios.

I’ll go into detail on Magick and the 42 lines of the framework later, but for now, let me explain how Magick uses these properties to handle your upgrades.

In Magick, there is a single feature, called and Upgrade feature, which handles all the hard work for you. This is where those 42 lines reside.

When activated, the Magick Upgrade feature will go through all features in your farm and look for features that have those two custom properties added. Then, it will sort them in the order of the UpgradePriority property, and finally, it will activate all the features that haven’t been activated already.

This too may sound extremely simple, and it is, but again, this simplicity hides awesome power and incredible flexibility.

Let’s say that you want to add a certain list with an attached content type. Using Magick, you would then add a feature to create the list, a feature to create the content type, and finally a feature to connect the content type to the list.

Your features would then, for example, have the following UpgradePriority numbers:

  • 15 List creation (web scoped)
  • 25 Content type creation (site scoped)
  • 35 Connect content type to list (web scoped)

Upon activating the Magick Upgrade feature, Magick will activate these features in order, even if they have different scopes. You don’t need to activate the individual features yourself or ask your users to do so.

After activation, the Magick Upgrade feature automatically deactivates itself so that it is ready to be activated again. Of course, because Magick only activates features that aren’t activated, clicking it again won’t reactivate the existing features, so there’s no danger of getting two lists.

Next time you want to make changes to your sites, you create a new solution with new features and ensure that you have unique UpgradePriority numbers, and upon activating the Magick Upgrade feature, those features will be activated for existing sites. For new sites, all features will be activated, and you’ve ensure that all your sites have the same features activated.

Neat, eh?

Can I use this for existing features?

A possible, although not supported, scenario is to tag existing features with the Magick custom properties. For example, if you want the Publishing framework to be available, you can technically modify the feature.xml file of that feature and add the custom properties to have Magick add it for you.

Keep in mind, though, that modifying existing features, especially the out-of-the-box features that ship with SharePoint, is not supported.

You can, of course, tag any of your own features as much as you like, to ensure you at least get your features activated in the correct order.

Paths and Priorities

The two custom properties that Magick needs give you great flexibility in targeting different exactly what to upgrade. I’ll go into more detail on how you can customize these properties to create different upgrade paths.

In this context, and upgrade path means a group of upgrades that Magick will handle as a separate set of upgrades. With a few modifications, you can even get Magick to automatically pick the right path for you.

If you’re allergic to .NET development, this means you actually need to have multiple features to activate multiple paths.

For example, you may want to have one path that upgrades Team Sites and another path that upgrades your custom Project Sites.

To accomplish this, you need to tell Magick which path to upgrade. There are multiple ways to accomplish this, and I’ll dig into the details of how to do so once I show you the actual code.

It is also vital that you keep track of the UpgradePriority numbers you have used. This is really a matter of strategy, and I’ll share some of my experience in picking such priorities with you. In short, however, a good strategy allows you to inject upgrades into previous solutions. For example, you may find out that as part of your content type deployment, you really wanted to add a new form to the list first. With Magick, that’s as simple as deploying a new feature with an UpgradePriority that precedes a previous feature.

Like I said, I’ll go into more detail on strategies later, and next, I’ll also show you the framework code that makes Magick… well, Magick.


Pin It

Magick and Continuous Upgrades

In explaining what Magick does in SharePoint, I’ve previously briefly described how awesome Magick the Framework is and what SharePoint problems Magick solves.

However, that’s just the start of what Magick does.

In this article, I’ll explain how Magick allows you to implement agile approaches to SharePoint development by supporting continuous upgrades and evolutions of your SharePoint solutions.

Oh, and if I haven’t mentioned it already or you haven’t guessed: Magick works across all SharePoint versions, at least from SharePoint 2007 and onwards.

What are Continuous Upgrades?

In Agile development, a key principle is that you build and deploy functionality very rapidly. In fact, in many cases, you create functionality every week of a long project, and users get access to that functionality immediately.

This approach is a win-win for both the developers and the users. Users get to see rapid progress and get access to important functionality as soon as it is ready, rather than having to wait for a long time until an entire software development project is complete.

This also allows them to give feedback during development, for example to suggest further improvements, new features, or changes to features they don’t like.

For developers, the continuous feedback and rapid deployment means they can find issues sooner and can vastly improve the solution. It also means that the development sprints, as these short development cycles are often called, are done sooner so one gets more variety in development and see the results of ones work more quickly.

However, in SharePoint, this approach is often very difficult due to the somewhat static nature of how SharePoint works. If you recall from the previous article, many SharePoint components cannot be changed ever after they have been deployed once. How can you then make continuous improvements and deploy updates on a regular basis?

In a Word: Magick!

In Magick, we not only support the static nature of SharePoint solutions, we encourage it. In fact, in Magick, we build a solution once and we never touch it again, at least in a perfect world.

That may sound strange for a framework that claims to be agile and support rapid changes first and foremost. However, it is really quite simple.

Magick wants you to think about changes in your solutions, and not how something came to be. In other words, we look at how we need to move from point A to point B, not how we got to point A in the first place.

In the traditional approaches to SharePoint solutions, you often start out by deploying a solution that does something. This is what gets you to point A. Traditionally, when you need point A to change, many developers will look to change the solution that got us there. In technical terms, they modify the solution file and redeploy the solution.

This is problematic from a number of perspectives.

First, many components cannot change after they have been deployed. This is due in part to Microsoft policies, but more fundamentally, due to the way SharePoint solutions work. Remember that SharePoint solutions are recipes for how to build something, and changing the recipe does not change the already produced goods.

In Magick, however, we never change a solution after it has been deployed, with the exception being .NET code which can change if required, but also should be left as much alone as possible.

Instead, we seek to create solutions that look at the current state of affairs and what is required to move to where we want to be.

Forgive my slight technical departure here, but let’s look at a fairly simple example.

You have deployed a great new solution for project management which includes a great new list of project tasks. After a couple of weeks, users come back to you and say that they really like it, but would like different options for sorting and filtering the list.

In traditional SharePoint development, you’d simply go in and modify the original solution to support the new requirement. This, of course, breaks Microsoft’s policies on never changing any declarative components, but more importantly doesn’t always work. Users may already have modified the list, and if you redeploy those lists with different functionality, you may break what the users have worked hard to accomplish.

In Magick, on the other hand, you would instead deploy a new solution that will modify the list and add whatever functionality the users requested. Depending on what change you want to make and the toolset you have, this allows you to check whether the new change will actually make sense in a particular situation.

Of course, doing more advanced detection requires .NET code, but if you can use that, you can just check whether the current view is unchanged from when you originally deployed it, and only change that view if the users themselves have not made the changes. Otherwise, you could create a new view for them, or simply not make the changes at all.

Are these types of changes supported? Yes, very much so. In fact, you are really just automating the tasks that the users would do themselves through the web interface, including the decisions made to determine if you want to perform those tasks.

If you are allergic to .NET code, fine, you can still make certain changes, but mainly to add new components rather than change existing ones. Like I’ve said many times, if you really want to get stuff done, use third tier development and .NET code 🙂

Solution Mayhem!

The keen observer will at this point ask two very important questions.

First, if you build new solutions for every change, wouldn’t you end up with dozens of solution files rather than a single, easy to manage WSP?

Second, if you create new features all the time, won’t you create complexity in deploying new sites or upgrade existing ones? You’ll end up with tons of features that you need to activate in the right order!

These questions are exactly what Magick handles for you. In fact, it doesn’t handle anything else.

For the first question, remember that in Magick, we never touch a solution file ever again after it has been deployed. A lot of the reason why administrators see WSP files as problematic is that they need continuous management. In Magick, they are deployed once and then forgotten. There are no upgrades, there are no changes, so management of multiple files is actually easier than managing just one file.

For the second question, I’ll show you later how Magick handles upgrades, but suffice to say, users rarely, if ever, see or need to see any of the features you deploy. Magick handles the upgrades for you, including making sure everything happens in the correct order, for the sites that need to be upgraded only, and within the scope required.

I’ll detail that in a future article, though, and then I’ll show you all the code, the conventions, and the Magick behind it all 🙂


Pin It