I had a slightly unusual situation. We’ve a customer who has using the Telerik RadEditor version 4.5.6 for SharePoint 2007. They’re upgrading to SharePoint 2010, and want their existing content to continue to work.

They’ve using the Telerik RadEditor web part quite a lot, so we had to keep that working. We’ve put in Assembly Binding Redirects using an SPWebConfigModification (more on that in a later post).

However, we also needed to put in the SafeControl entry for the old assembly. Maurice Prather discusses this here. The short of it is:

What happens to your Web Part when it’s redirected to version Y?

1. On first render of a redirected Web Part instance (this is a KEY thing to remember), if the SafeControl for version X exists, an attempt to load the Web Part is made.
2. The .NET framework kicks in and redirect to version Y is successfully made.
3. SharePoint notices that the Web Part type guid (nothing we the Web Part developers can explicitly control) has changed and saves the new type id back to the database.
4. From that point forward, the next time the Web Part is loaded, the call is made directly for version Y.

Take a look at step #3. This is key. The database actually contains a reference to your web part in a form of a guid. The guid is a calculated value that allows the SafeMode parser to rapidly associate the serialized form with a live class type. The important thing to remember is that this reference lives on a per-page reference (i.e. page ABC has reference to web part types M, Q, V).

Why is this important? Until all instances of Web Part version X have been rendered, you cannot remove the SafeControl reference to version X unless you want bindingRedirect to fail.

Okay, fine. That makes sense, and I don’t have a problem marking a web part that we’ve been using for ages as safe, even if it will ultimately be updated in all instances by the redirection.

So, I put a new SafeControl entry into on the SharePoint Project Items of my solution.

(Please note: below I’ve used an assembly called ‘MyAssembly’. I’ve changed the name from the real assembly ‘cos I’m not sure I’m allowed to talk about it. But I’m showing the behaviour I saw).

This was then included in my Manifest:

However, when I went and checked the web.config I saw:

WTF? As best as I can determine, the assembly information in my SafeControls entry in my solution’s manifest has been ignored. The entry in the manifest lives within a particular Assembly element, so presumably SharePoint itself chooses to read the information from the assembly, rather than the manifest! (Why ask for the information then?)

Consequently, I found that the best option I had was to write an SPWebConfigModification to add my Safe Control entry. And that worked nicely.

Conclusion: If your WSP doesn’t contain the assembly you’re trying to create a SafeControl entry for, you’ll probably need to use an SPWebConfigModification. That seems a shame, given that Visual Studio 2010 appears to let you create other Safe Control entries, and puts them into the manifest correctly.