in

Dot Net Mafia

Group site for developer blogs dealing with (usually) .NET, SharePoint 2013, SharePoint 2010, Office 365, SharePoint Online, and other Microsoft products, as well as some discussion of general programming related concepts.

This Blog

Syndication

Archives

Corey Roth [MVP]

A SharePoint MVP bringing you the latest time saving tips for SharePoint 2013, Office 365 / SharePoint Online and Visual Studio 2013.

Feature Versioning and Upgrades in SharePoint 2010

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.

Comments

 

decatec sharepoint team said:

This versioning seems excellent news for all people deveoping stuff using Visual Studio and WSP Builder ...

January 10, 2010 3:02 PM
 

SharePoint Content Type Lifecycle Management « <CharlieDigital /> said:

Pingback from  SharePoint Content Type Lifecycle Management &laquo; &lt;CharlieDigital /&gt;

May 3, 2011 8:38 PM
 

Unknown said:

Does the UpgradeActions, or more specifically the AddContentTypeField parameter requires the usage of a feature receiver?

I'm to add a field to a pre-deployed content type, but my deployment feature (site collection feature) doesn't have a receiver (to avoid gac deployment).

September 13, 2011 12:09 PM
 

CoreyRoth said:

@Unknown I don't believe a feature receiver should be required.

September 15, 2011 5:24 PM
 

Karsten Pohnke said:

Thank you Corey for the great post!

I agree with you, it can put some more complexity into your solution, but what other options do we have, if we want to update for example a content type which is already in use by a list?

Have a nice day...

April 19, 2012 4:28 AM
 

Rabi said:

Same questions @Karsten. what other options do we have, if we want to update for example a content type which is already in use by a list? what will be steps??

July 13, 2012 1:41 PM
 

noonesshadow said:

This has probably changed, but I've managed to use it by simply pointing to main (and only) manifest file (list schema in my case) in ElementManifest and listing new fields in AddContentTypeField

December 12, 2012 2:15 PM

Leave a Comment

(required)  
(optional)
(required)  
Add

About CoreyRoth

Corey Roth is an Applications Architect at Infusion specializing in ECM and Search.
2012 dotnetmafia.
Powered by Community Server (Non-Commercial Edition), by Telligent Systems