2

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

3 Answers 3

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

4
  • Wictor, totally understand that requirement this is purely for a Continuous Integration project though and not for a full release build. I have been thinking of a few other options and will update as soon as I have tested them.
    – Mauro
    Aug 23, 2010 at 15:52
  • Still, even if you are using CI you should think of a production environment, otherwise you need to start from the beginning over and over again... Aug 23, 2010 at 16:10
  • So... would the best method be to create the user controls in their own gacced dlls and reference them from the web parts? should we not increment the web part build revisions?
    – Mauro
    Aug 24, 2010 at 7:19
  • Yes, you could do that but then you must also make sure that you use assembly redirection as Anders shows below and/or use feature stapling.Even though assembly redirection works fine, SharePoint still is very sensitive to versioning (which is why I try to not to change it for each build) Aug 24, 2010 at 13:22
1

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

1
  • Cant upvote yet, but thanks for the information.
    – Mauro
    Aug 23, 2010 at 14:26
0

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.