If you've never visited the site before, you may want to subscribe to my RSS feed, or create an email subscription using the link at the top. Enjoy the site, and thanks for visiting!

Web Part Versioning in SharePoint

During my investigations into this issue, I came across three potential approaches. Hopefully detailing these will shed some light on why I approached web part versioning in the manner that I did.

Standard, incremental versioning

My versioning practice largely ignores the revision part of the version. I version using major, minor, and build numbers; incrementing the build version for bug fixes, the minor number for minor changes, and the major version for larger changes.

As a result, my plan was to use the same approach for web parts. In practice, however, I found that there were issues with this. As SharePoint installs and uninstalls web parts by the name of the cab file, each version would require a different file name. Alternatively, the old version could be removed and the new version could be installed. If the former approach is used, all pages containing the previous version must be manually updated in order to use the new version. If the later approach is used, all pages containing the previous version with display an error, which will require manual intervention also.

It should be possible to work around this using Publisher Policy files, however…

Standard, incremental versioning using Publisher Policy files for version control

Publisher Policy files can be created to redirect requests for an assembly to a specific version. Publisher Policy files are created and added to the Global Assembly Cache. The creation of these files isn’t as straightforward as it should be, due to issues with Visual Studio. I did manage to find a workaround for this, using build events and other techniques. So far, so good.

One Publisher Policy file is required for each major or minor version you wish to redirect. For example, a single policy file can redirect all calls for version 1.0.*.* to version 1.1.*.*. This is acceptable to being with, but upon reaching version 1.7.*.* of an assembly, a large number of Publisher Policy files are required. This must all be managed, built, packaged, and installed resulting in a significant overhead.

To further complicate matters, SharePoint identifies these Publisher Policy files, and updates its internal reference (ie dwp’s) to the target version. Removing the Publisher Policy file should remove the redirection to the newer assembly; this is the behaviour when using the same approach for libraries. However, because SharePoint updates its references, removing the Publisher Policy file has no effect on the version SharePoint is using, meaning rollback becomes largely impossible.

It may be possible to use Publisher Policy files to refer SharePoint back to the older version, if rollback is required. This would require one Publisher Policy file for every major/minor revision, both up and down the version tree. Again, this is an unacceptable overhead, and has the potential to become unmanageable.

Fixed versioning

In the midst of all the apparent madness detailed above, I contacted a developer by the name of Tariq Ayad (
http://geekswithblogs.net/tariq/) to enquire as to his thoughts on web part versioning. Tariq is well respected in SharePoint development, and its widely acknowledged that he “knows what he’s doing”.

Tariq said that due to the myriad issues involved, he was using a fixed version, but labelling the web parts himself. He had found no better approach at that time.

Given all the issues above, I decided that this approach was almost certainly for the best. I did have the idea to take the concept one step further through the implementation of a “meta” version property, which is exposed within SharePoint using a custom tool part (information on how to do this can be found on Simon Tocker’s blog - link below - as he did the leg work on implementing it). This meta version displays the Web Part version, but the assembly version always remains at 1.0.0.0. As does the version reference in the .dwp files.

As a result of this, web parts can be easily upgraded, with no administrative overhead. The version can still be tracked using the meta-version attribute.

Simon Tocker has posted some example code related to the concept on his blog, Binary Jam.