SharePoint WebPart Versioning

WebPart versioning is a discussion that I have with clients, as well as internally, consistently. Largely this is because it can hit sensitive organizational points (if they have a reasonable software development initiative) and is terribly prone to developer opinion. It can rapidly move from a pragmatic to esoteric discussion.

For these reasons, it is challenging to structure a best practice regarding WebPart versioning, since there really is no best practice. However, after presenting some options I think it is reasonable to assume that an organizational best practice can be cultivated and everyone can be happy.

To try to get those gears turning, I am going to fly through at a 10,000 foot view of various problems typically encountered when implementing a WebPart versioning strategy, some approaches, and a base class that I use that leverages one of the discussed version approaches using a display vehicle I like the most.

Before I continue, let me state that the remainder of this post is going to assume strong named/signed assemblies, as well, these assemblies are being stored in the GAC.

Problems with Versioning

Arguably, the most difficult segment to tackle when dealing with WebPart versioning is that the AssemblyVersion attribute tends to be of little use because WebParts can be considered to use static versioning. AssemblyVersion within orthodox managed development tends to be heavily leveraged because it defines an integral number regarding the assembly’s identity. So, why is the AssemblyVersion such an ineffective mechanism to rely on when dealing with SharePoint WebPart development?
There are three main reasons:

Referencing the AssemblyVersion attribute, as managed assemblies in the GAC do, will break if this value changes.

The SharePoint WebPart Description File (.webpart or .dwp) references the AssemblyVersion attribute within the type element in its XML structure. This element consists of a string with type and assembly information about the corresponding webPart element. As a result, any description files already instantiated on a page won’t bind right due to an incorrect assembly version number.

Without modifying the safe controls entries for the SharePoint site, there will be an assembly mismatch when altering the AssemblyVersion number, resulting in a safe control error when attempting to render the WebPart (if already on a page, otherwise it won’t be allowed on the WebPartPage). This can be solved with solution redeployment or manual web.config modifications; however you are following still subject to the same problem as described above so while fixable, isn’t a rational solution.

There are some more issues, most I consider negligible so I won’t go over them; however those are the largest ones.

Versioning Storage

In order to resolve not having a dependency on the AssemblyVersion, a margin of people rely on the AssemblyFileVersion attribute since this can arbitrarily change with little effect on the WebPart. Use of this also provides the same experience as using the AssemblyFileVersion since this value is mutable from VS.NET with nearly the same invocation. As well, for people that are using Reflection in order to hydrate objects with the relevant assembly information, the mechanics are consistent once you have an Assembly object.

Otherwise, static string representation is simple and popular. This involves setting the values of the version and build name within the assembly, a satellite assembly, or from some other arbitrary source. It could be a wide range of objects, even from a tabulated text file, it doesn’t really matter. All that matters is that the version information is read from a source, and that source is not the calling assembly.

Choosing a Display Vehicle

The display mechanisms for versioning vary depending on the organization. I have seen in the majority of projects these four major types:

Toggle the corresponding SharePoint Feature description element prior to the SharePoint solution packaging.

Just format and dump it out to directly out to standard output as part of the control.

Add a new WebPartVerb object to the current instance WebPartVerbCollection with the version information.

Add a new EditorPart to the current instance EditorPartCollection with the version information

Making It Work

As an example, I am going to use the last option, and place my versioning information in an EditorPart object. In order to consistently enforce this across multiple WebPart type projects, a new base WebPart class for subclass use will be defined which contains all the relevant code to handle the versioning. In order to pass unique values for the program name and the version number, the derived class constructor will be used. The approach is similar to using the WebPartVerb approach, and could easily be ported over to that construct if EditorPart  objects don’t really blow your back.

To do this, three different classes are used. VersionInfo contains a static method that renders to standard output the required strings using strongly typed formatting objects. EditorVersionPart inherits from the EditorPart class, and contains two backing fields that are toggled in the constructor. EditorVersionPart calls the static VersionInfo.CreateVersion method to build out the visual representation of the version information. The WebPartBase class inherits from the WebPart, and IWebEditable interface. Regarding the latter of these, its type members are implemented, which call the custom EditorVersionPart class.

As a result of using this class, you will be presented with the following when using it as your base class, demonstrated in a trivial WebPart.

In order to provide the required strings, in the WebPart constructor the desired values are being provided.

As a result, the WebPart class structure will take on the following form:

namespace buenz.SharePoint.WebParts
public class VersionDemo : WebPartBase
public VersionDemo()
_name = “My WebPart”;
_version = “ (Debug / Checked)”;

And the related classes to achieve this effect are:

using System;
using System.Collections.Generic;
using System.Web.UI;
using System.Web.UI.WebControls;
using System.Web.UI.WebControls.WebParts;
using Microsoft.SharePoint;
using midwave.SharePoint.WebParts;

namespace buenz.SharePoint.WebParts
public class VersionInfo
public static void CreateVersionSegement(HtmlTextWriter writer, string version, string name)
var tbl = new Table {HorizontalAlign = HorizontalAlign.Center};
var row = new TableRow {HorizontalAlign = HorizontalAlign.Center};
var versionRow = new TableRow {HorizontalAlign = HorizontalAlign.Center};
var cell = new TableCell {HorizontalAlign = HorizontalAlign.Center, Text = string.Format(“{0}”, name)};
var versionCell = new TableCell {HorizontalAlign = HorizontalAlign.Center, Text = string.Format(“{0}”, version)};

public class EditorVersionPart : EditorPart
public string _name;
public string _version;

public EditorVersionPart(string webPartID, string name, string version)
Title = “WebPart Versioning”;
ID = string.Format(“MyEditorPart{0}”, webPartID);
_name = name;
_version = version;

protected override void RenderContents(HtmlTextWriter writer)
VersionInfo.CreateVersionSegement(writer, _version, _name);

public override bool ApplyChanges()
return true;

public override void SyncChanges()

public class WebPartBase : WebPart, IWebEditable
public string _name;
public string _version;

EditorPartCollection IWebEditable.CreateEditorParts()
var editors = new List {new EditorVersionPart(ID, _name, _version)};
return new EditorPartCollection(editors);

object IWebEditable.WebBrowsableObject
get { return this; }



Happy Versioning! :)



  1. Jim Sally says:

    Here’s the article that Mr. Draper and I worked on last year on some of the same points:

  2. Daniel McPherson says:

    Hi Adam,

    Some really good thoughts, appreciate you sharing this. Just a quick question, have you looked into what happens if use Assemebly Redirects? Not saying this is the way to go, but I’m just curious as to whether it overcomes some of the issues you have raised?

    Let me know,

  3. sharepoint_consulting says:


    Good article. Thanks for sharing.


  4. Wictor says:

    I posted about some alternative ways, including my preferred way – assembly redirection, here

  5. Ryan says:

    What you should be doing is keeping the AssemblyVersion consistent and changing the FileVersion attribute. Then no need for mucking around with redirection. This is what MS does and recomend, you don’t have multiple assembly versions of SharePoint.dll (v12.0.0)


  1. definition ui strings | Digg hot tags - [...] Vote SharePoint WebPart Versioning [...]
  2. Links (12/11/2008) « Steve Pietrek - Everything SharePoint - [...] SharePoint WebPart Versioning [...]
  3. SharePoint Daily for December 12, 2008 - SharePoint Daily - Bamboo Nation - [...] SharePoint Web Part Versioning (Adam Buenz)Web Part versioning is a discussion that I have with clients, as well as…
  4. WSS 3.0 & MOSS: Recopilatorio de enlaces interesantes (XXIV)! - Blog del CIIN - [...] Gran artículo de Adam Buenz sobre el versionado de web parts. [...]
  5. WSS 3.0 & MOSS: Recopilatorio de enlaces interesantes (XXIV)! « Pasión por la tecnología… - [...] Gran artículo de Adam Buenz sobre el versionado de web parts. [...]

Leave a Reply

Your email address will not be published. Required fields are marked *