3

I (successfully) deployed some sharepoint2010 - Webparts using msbuild. Everything works fine until I decided to change the assemblyVersion. Whenever I do that the message

Web Part Error: A Web Part or Web Form Control on this Page cannot be displayed or imported. The type RTContacts, RTContacts, Version=1.0.0.0, Culture=neutral, PublicKeyToken=2721ba85ef1e4b88 could not be found or it is not registered as safe.

A solution would be to stay on 1.0.0.0, but there should be a better way...

Perhaps interesting to mention is that we use a centralized AssemblyFile which is included as a link.

The manifest contains the correct assemblyversion:

<Assemblies>
<Assembly Location="RTContacts.dll" DeploymentTarget="GlobalAssemblyCache">
  <SafeControls>
    <SafeControl Assembly="RTContacts, Version=1.0.4325.18399, Culture=neutral, PublicKeyToken=2721ba85ef1e4b88" Namespace="RTContacts" TypeName="*" />
  </SafeControls>
</Assembly>

When I add the WebPart again to that Site, it is displayed correctly, but already existing webParts seem to link to the old version.

Ole Albers
  • 8,715
  • 10
  • 73
  • 166

2 Answers2

5

You are having these problems because you're using the versioning attributes incorrectly.

If you examine, for example, Microsoft.SharePoint.dll in Reflector you will see v14.0.0.0 (for SharePoint 2010).

This AssemblyVersion will stay exactly the same for Beta, RCx, RTM all service packs and CU's etc - the only thing that changes is the AssemblyFileVersion (this is the thing you see in Windows Explorer under properties)

See this for more details

SharePoint features: How can I use wildcard assembly versioning?

But don't take my word for it - Microsoft KB556041 - How to use Assembly Version and Assembly File Version

If you follow this then no Assembly binding redirections are necessary and when you update your web part the existing instances will not be broken.

Community
  • 1
  • 1
Ryan
  • 23,871
  • 24
  • 86
  • 132
  • We decided to do a "dirty" solution. Leave the AssemblyVersion on 1.0.0.0 and using AssemblyTitle to save "our" version number. In combination with a webpart that shows the AssemblyTitle of all webparts this is a dirty but working solution for us. – Ole Albers Nov 08 '11 at 12:49
  • 1
    Its only a tiny step from 'dirty' to correct - leave AssemblyVersion as 1 and put your version info in AssemblyFileVersion. You can even output the AssemblyFileVersion info on the web part (I put it in a toolpart for easy troubleshooting). Job done. – Ryan Nov 08 '11 at 16:02
  • 1
    its been a while. Just wanted to tell you we did the clean solution after a while :) – Ole Albers Aug 09 '12 at 12:22
2

Original question: How to fix the "Not registered as safe" error after the assembly version has been changed?

Web Parts are registered as safe in the web.config files.

Appropriate entry looks like this:

<SafeControl Assembly="MyWebPartLibrary, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null"
  Namespace="MyWebPartLibrary"
  TypeName="*"
  Safe="True"
  AllowRemoteDesigner="True"/>

Modify the Assembly attribute and replace the old version number with a new one.

Current question: How can I change assembly version without having to re-add all the Web Parts to the page?

I think you'll need to use assembly redirection to keep existing Web Part instances working:

<runtime>
  <assemblyBinding>
    <dependentAssembly>
      <assemblyIdentity name="RTContacts" publicKeyToken="2721ba85ef1e4b88" culture="neutral" />
      <bindingRedirect oldVersion="1.0.0.0" newVersion="1.0.4325.18399" />
    </dependentAssembly>
  </assemblyBinding>
</runtime>

Read the article Web Part Versioning with assembly redirection for a detailed analysis of this problem.

Marek Grzenkowicz
  • 17,024
  • 9
  • 81
  • 111
  • GAC, manifest and web.config are all the same and correct, but restart did not help – Ole Albers Nov 04 '11 at 09:30
  • Oh. I just found out that the message said that V 1.0.0.0 cannot be found. Sorry I did not mention it early but that information was hidden behind another layer. – Ole Albers Nov 04 '11 at 09:47
  • I just updated the description: The Webparts that are already on my Pages throw the error. If I add the same Webpart again on that Page it works correctly. Re-adding all webparts each time we deploy a new version would be a bit of a hazzle as there are about 10.000 Pages already in the project. Also I am absolutely sure that we did not have any hardcoded version in our webparts. I wrote that completely by myself and there is not much magic in there – Ole Albers Nov 04 '11 at 10:03
  • Thank you for your patience. Not really a "nice" solution but the best that can be done in sharepoint, I think. – Ole Albers Nov 04 '11 at 10:19
  • 1
    Chaps - you're making really hard work of this! See my answer for the recommended method that doesn't have these problems. – Ryan Nov 07 '11 at 09:38
  • @Ryan Downvoting my answer seems to be a little harsh, but +1 for the KB556041 link nonetheless. – Marek Grzenkowicz Nov 07 '11 at 10:30
  • Sorry Marek - but I just don't agree that this is the right way to tackle this scenario and voting is how you make your opinions known on SO. It was nothing personal and I do heavily upvote as well! – Ryan Nov 07 '11 at 13:15