Update Web Part in Custom Site Definition and created sites

Question

I have a site definition with a custom web part, the projects (both the site definition and the web part) are part of a CI build which means the version numbers are incremented each build.

The process is as follows:

1. The web part assembly changes each build
2. The site definition has the correct version of the web part defined in the onet.xml file.
3. The sites using the Site Definition are only ever created if the site is not present as part of the build.
4. When browsing the site (after a new build) each of the web parts is showing an error:

My thoughts are that I will have to write a script as part of the build that will loop through each page in the sites using the custom site definion and replace the references for the old web part assemblies for the new ones, is this correct? is there a simpler way of doing this?

I've tried "Reset to Site Definition" but this didnt work - other than an IIS Reset does this require a server reboot too?

Web Part Definition in onet.xml

   <AllUsersWebPart WebPartZoneID="WP_Zone_Top_Right" WebPartOrder="1">
      <![CDATA[
      <webParts>
        <webPart xmlns="http://schemas.microsoft.com/WebPart/v3">
          <metaData>
            <type name="$(NameSpace), Version=$(VersionNumber), Culture=neutral, PublicKeyToken=$(PublicKey)" />
            <importErrorMessage>Cannot import this Web Part.</importErrorMessage>
          </metaData>
          <data>
            <properties>
                <!-- properties removed -->
            </properties>
          </data>
        </webPart>
      </webParts>

      ]]/>
    </AllUsersWebPart>

The webparts are created using ASCX user controls which are then instantiated by the actual web part.

The namespace, versionnumber and public key are set at build time. If the sites are not created then no error is displayed (the web part is correctly rendered) the the sites exist though then the error saying that the web part is not registered as safe or cannot be found is displayed.

The web part is also re-deployed as part of the same build by doing a full cycle of:

1. Deactivate
2. Retract
3. Uninstall
4. Install
5. Deploy
6. Activate

Answer 1

Just to raise a finger of warning!!

It is not supported to edit/change/update a site definition once you have provisioned a site using it. The only thing supported is to change the flag wheather it is hidden or not. This means that you should NOT increase the version of the assemblies in your site definitions without actually creating new site definitions (and hide the old ones) for EACH build! Sounds like a very crazy scenario.

You must use assembly redirection, feature stapling or other programmatic approaches to update an existing site definition.

IMHO you should reconsider your solution and use feature stapling!

To read more what is supported and not check out this KB article: http://support.microsoft.com/kb/898631/en-us

Answer 2

Incrementing assembly versions in SP2007 was a real pain, and hence avoided by most people. In SharePoint 2010 it has become easier as there is declarative support for binding redirects.

it is not enough to replace your safecontrols in web.config, because assembly version is part of the type name in the webpart manifest, and hence is all over the content database.

you need to define binding redirects as part of your solution but at the same time keep the old binding redirects since the type name in the content database wont change until first time the web part is rendered.

Read Maurice Prathers excellent article on this here

Answer 3

How are you referencing the web part binaries? I'm thinking that a script would merely only have to update the version numbers in the SafeControls section of web.config rather than "looping through each page in the site".

An easier way to get round this I think is to use ASCX user controls for your web part contents and functionality rather than putting the entirety of the web part functionality within the web part class itself - difficult if you've already done so much in the latter way.