Sharepoint on Ulitzer

One new feature in SharePoint 2010 is the ability to version and upgrade features. 

I haven’t seen a lot of people talking about it yet, so I thought I would take a few minutes to talk about it today. 

 It’s an interesting new feature and I’ll be curious to see how much people use it and when. 

The versioning aspect of features is interesting, but specifically what we’ll be talking about today are what kinds of things we can do when we perform a feature upgrade. 

Unfortunately, by the time you read all of this, it will probably leave you with more questions than you started with. 

You will probably be asking yourself a lot of questions like “well, what happens when I upgrade a feature and it has X in it?”.

The first thing to know is that SharePoint 2010 makes use of the Version attribute on the Feature element now. 

We can then use this version to execute code or do various things in an element manifest. This is also an easy way to add a new site column to a content type which we’ll talk about in a bit.  It all starts with the UpgradeActions element in your feature.xml.  It takes a ReceiverAssembly and ReceiverClass attribute just like the Feature element takes. 

Here is what it would look like.

If you’re not going to be executing custom upgrade action code, you can leave that part out the assembly.  You can then optionally add a VersionRange that takes BeginVersion and EndVersion attributes.  You can specify multiple VersionRange elements to handle upgrades across multiple versions with one file.  You can then specify what you want to occur on the feature upgrade. 

One of the most common things you can do is to specify a separate element manifest file which deploys various things to SharePoint when the solution is upgraded.  This file will have the same syntax as any other elements.xml file you have used.  Here is what that would look like.

Another thing you can do is rename a file.  So if you deployed a file called default.aspx and now you want to be called default2.aspx, you can have your upgrade make the change.  I have no idea if it would actually update anything that references the file.  I would guess not, but it’s there to try out if you ever need it.

One thing, that is pretty interesting is the ability to add new site columns to an existing content type.  The syntax is pretty similar and it will even push down changes to content types that inherit from it.  Just specify the ContentTypeId, FieldId, and whether or not you want it to PushDown. 

The last thing to mention is that, you can execute custom code when a feature is upgrading.  If you have some complex upgrade logic this is the way to go.  It works by overriding the FeatureUpgrading event handling method.  It passes the UpgradeActionName and an IDictionary of parameters.  I’m not going to go into what the code looks like on a feature upgrade today, but I will cover it in a future post soon.  Here is what a complete UpgradeActions element might look like in your feature.xml.

I’ll be really curious to see how and if people use feature upgrades.  It definitely seems like it can be useful, but I don’t know if I will want to have my feature broken out into a bunch of different manifest files when I start having lots of upgrades.

Read the original blog entry...