The good solution for versioning SharePoint 2010 webparts

Artigo
07/18/2011

Everyone who has had the pleasure of working in a team with other developers and using TFS with auto-incrementing version numbers most probably have faced the issue with webparts breaking after an increment in version numbers. This effect is not at all strange, as SharePoint keep the full signature of the class behind the webpart and as this changed it will not know how to render the webpart.

To solve this problem, a very easy workaround is to create a class in a separate assembly that inherits from the version-controlled webpart .cs file and implements the actual webpart. This way the non-version controlled part of the code is very thin and SharePoint is still happy with it. Problem of this solution is that it requires and additional assembly file and also generates quite some overhead (SPWebConfigModification class) when packaging your solution.

Come SharePoint 2010, a lot nicer solution is available:

You could even omit the NewVersion tag and have a wide OldVersion range.

One thing to be careful of is keeping old SafeControl entries. If you remove them, assembly redirection will not work as the original assembly will not be loaded. This results in SharePoint also not updating its references to the old assembly version. Also keep in mind that SharePoint updates assembly references page-by-page when they webparts on the page are loaded, so all pages need to be “touched” in order to get rid of old references.

To get around the bug with leading zeros in the public key token’s bytes make sure you are at least on the June 2011 CU.

More info on the issue:
https://www.bluedoglimited.com/SharePointThoughts/Lists/Posts/Post.aspx?ID=313

And the resolution:
https://blogs.msdn.com/b/mcsnoiwb/archive/2011/07/18/assembly-binding-redirection-bug-fixed-in-june-cu.aspx

Partilhar via

The good solution for versioning SharePoint 2010 webparts

Recursos adicionais