The Latest Time Saving Tips for Your SharePoint Deployment

Corey Roth

Subscribe to Corey Roth: eMailAlertsEmail Alerts
Get Corey Roth: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Related Topics: Intel XML, XML Magazine, SharePoint Archiving Journal, Microsoft Developer

Blog Feed Post

Feature Versioning and Upgrades in SharePoint 2010

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

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.

<UpgradeActions ReceiverAssembly="MyFeatureReceiver, Version=1.0.0.0, Culture=neutral, PublicKeyToken=3e1b35c83d6e53f4"

  ReceiverClass="MyFeatureReceiver.MyFeatureReceiver">

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. 

<VersionRange BeginVersion="1.0.0.0" EndVersion="1.9.9.9">

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.

<ApplyElementManifests>

  <ElementManifest Location="WebPart1\UpgradeManifest.xml"/>

</ApplyElementManifests>

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.

<MapFile FromPath="OldFilename.aspx" ToPath="NewFilename.aspx" />

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

<AddContentTypeField ContentTypeId="0x010100F15ADB2FA333AD49848E7E01BC79C9750202"

                     FieldId="{b63c6371-f774-451d-b4fb-5679625fafd5}"

                     PushDown="TRUE" />

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.

<UpgradeActions ReceiverAssembly="MyFeatureReceiver, Version=1.0.0.0, Culture=neutral, PublicKeyToken=3e1b35c83d6e53f4"

  ReceiverClass="MyFeatureReceiver.MyFeatureReceiver">

  <VersionRange BeginVersion="1.0.0.0" EndVersion="1.9.9.9">

    <ApplyElementManifests>

      <ElementManifest Location="WebPart1\UpgradeManifest.xml"/>

    </ApplyElementManifests>

    <AddContentTypeField ContentTypeId="0x010100F15ADB2FA333AD49848E7E01BC79C9750202"

                         FieldId="{b63c6371-f774-451d-b4fb-5679625fafd5}"

                         PushDown="TRUE" />

    <CustomUpgradeAction Name="MyCustomUpgradeAction">

      <Parameters>

        <Parameter Name="Parameter1">Some Value</Parameter>

        <Parameter Name="Parameter2">Some Other Value</Parameter>

      </Parameters>

    </CustomUpgradeAction>

    <MapFile FromPath="OldFilename.aspx" ToPath="NewFilename.aspx" />

  </VersionRange>

</UpgradeActions>

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...

More Stories By Corey Roth

Corey Roth, a SharePoint Server MVP, is a consultant at Hitachi Consulting specializing in SharePoint and Office 365 for clients in the energy sector. He has more than ten years of experience delivering solutions in the energy, travel, advertising and consumer electronics verticals.

Corey specializes in delivering ECM and search solutions to clients using SharePoint. Corey has always focused on rapid adoption of new Microsoft technologies including Visual Studio 2013, Office 365, and SharePoint.

He is a member of the .NET Mafia (www.dotnetmafia.com) where he blogs about the latest technology and SharePoint. He is dedicated to the community and speaks regularly at user groups and SharePoint Saturdays.