How can I make sure the features in my solution activate in the correct order?

Question

I'm working on a fairly large SharePoint 2010 project. We have broken up the code into a number of solutions, each containing a number of features which we deploy via powershell and activate in the target environment. So far so good.

However, the problem we now face is that because some features are dependent on others, we need to ensure they are activated in the correct order. At the moment we do this by having deployments done by someone who just "knows" what order to use and keeping the magic sequence in a team wiki.

However, we'd be much happier if we could automate the activations somehow. The idea we have come up with is a "feature activating feature" or "one feature to rule them all" which would give us a one click "activate all" function. The hope is that all we have to do is maintain this one feature and all of our subsequent deployments will have their features switched on in the right order.

My question is this - is this a reasonable thing to create or have we lost it? Is there a better way of ensuring that our feature constraints are met?

Answer 1

You mention that you already have PowerShell scripts to deploy your packages. That is a good start. I would recommend starting from Gary Lapointe's excellent Deploy-SPSolution scripts for this purpose.

You should make sure you have configured feature dependencies appropriately for your solution, this will ensure no one can make mistake and activate them in the wrong order. SharePoint is also able to auto-activate dependencies of same scope, so it could save you a few clicks.

For feature activation itself, you have several options.

• Activate using a few more PowerShell scripts (requires shell access)
• Activate your features in your Onet.Xml (if applicable. The order of activation will be the order of appearance inside Onet.xml)
• Have a "feature activation feature"

The last option is perfectly acceptable, in fact as an added bonus you can put all your other features Hidden and clean up the Features list in the UI.

For example this snippet will activate a list of features from their Guid, in the given order:

List<Guid> webFeaturesToActivate = new List<Guid>() {
    new Guid("4aaa8b48-0cd9-4458-acdf-503f8b38cb44 ")
    // etc.
};

// Activate all required web features not already active
var activeWebFeatures = (from f in web.Features select f.DefinitionId);
webFeaturesToActivate.Except(activeWebFeatures).ToList()
    .ForEach(delegate(Guid featureId)
    {
        web.Features.Add(featureId);
    });

Answer 2

You can implement feature dependencies to ensure the features are activated in the right order. Check this blog on how to include feature dependencies.

I am not sure of your feature scopes (site, web) in your application, but if you want to create a master feature, you can do this by creating a empty feature which has dependencies on your features. Next set Hidden=True on your features (hides on web interfaces, so you have only master feature available). Dependent features which are hidden are activated by default when the parent feature is activated. Check this blog for more information on activation dependencies and rules. But again its dependent on how your features are scoped.

You can ofcourse use powershell to list out features in the order of activation as others have stated.

Answer 3

If you are going to be activing these features from the web interface, a quick solution is to use a naming convention that lists the solutions in alphabetical order. eg:

CompanyName.ProjectName.A.MySolution.InitStuffFeature 
CompanyName.ProjectName.B.MySolution.DoWorkFeature
CompanyName.ProjectName.Z.MySolution.FinalizeFeature

Answer 4

In the past SharePoint versions, STSADM is just okay, but it’s limited and hard to play with. However, with Visual 2010/TFS in collaboration with Windows PowerShell, you can completely perform the build automation (from Development Farms to QA/Test and Production), and also define the sequence in which Features should be activated. If something can be put into automation, then why bother to click through it manually every time?

Development Farms If you're talking about the Development Farms, you can configure running PowerShell cmdlets in Visual Studio 2010 post build events. You can set up the sequence of Fetaures activations in your ps1 files. Here is the Microsoft's take on Using Windows PowerShell Scripts to Automate Tasks in Visual Studio.

For QA/Testing/Acceptance and Production Farms I would strongly recommend you to implement an automated WSP deployment as part of a Team Foundation Server (TFS) build. Here is take from a Chris (Microsoft MVP) on how to configure it.