Well what a great gotcha I had today.  I have a WSS application you know custom list templates, event receivers web parts, everything you can think of except workflow.

So I have an upgrade for this, its a new dll and feature files.  I use a build server that can automatically update the AssemblyVersion and automatically edit the dwp aspx ascx files etc to set the version number of the build, its very slick.

Forgetting one thing.  SharePoint has never liked Version numbers. So I applied the update and my webpart fails with safe control errors. 

I forgot when you add the webparts it copies the dwp complete with version number into the content database and I just uninstalled that DLL. DOH! 

After figuring this out with the help of Captain Literal.Net, I stopped my build auto updating the versions and grepping the files etc.  It still marks the file version number to help the support guys but not the AssemblyInfo DLL versions now.

According to the Cap’n its not just the webpart dwp’s but lots of other features (small F)  that don’t like changes to AssemblyVersions, in fact there is code in SharePoint that deliberately IGNORES policy files.

So there you have it, again Versioning is a bit dodge in Scarepoint. Choose when to do it and know what the effects will be.  And don’t forget to take those *’s  (stars) out of the AssemblyVersion attributes and FIX it to

However you can change the Feature.XML file and change the Feature versions this doesn’t have any effect that we have noticed.

Im thinking of throwing together a feature that reads all installed features (hidden or not) and displays the details like title, description and version.

Technorati Tags: ,,