I'm migrating a solution from MOSS2007 to SharePoint 2010.

I have, among others, custom workflow actions in a DLL deployed to the GAC (e.g. MyWorkflows.dll version

My new solution contains new workflow actions that target the SharePoint 2010 API (e.g. MyWorkflows.dll version

So what I'm doing is:

  • Creating a workflow in SPD in a MOSS2007 environment. Such workflow contains one of my custom actions.

  • Upgrading the environment to SharePoint 2010.

  • Removing the WSP package containing my files/DLLs that targeted MOSS2007 and deploying a new WSP containing the solution files that target SharePoint 2010.

  • Add assembly redirection entries in the web.config file of my web application, so that calls to MyWorkflows.dll get redirected to MyWorkflows.dll version (I also add other redirection entries regarding other stuff - for example, webparts).

  • Reset IIS and OWSTIMER.

After that I can see that the old webparts work fine (the assembly redirection seems to work for them). However, when I try to run a workflow (manually, from the browser) it doesn't work. I get the following error in the ULS log:

Microsoft.SharePoint.SPException: at Microsoft.SharePoint.Workflow.SPNoCodeXomlCompiler.LoadXomlAssembly(SPWorkflowAssociation association, SPWeb web) at Microsoft.SharePoint.Workflow.SPWinOeHostServices.LoadDeclarativeAssembly(SPWorkflowAssociation association) at Microsoft.SharePoint.Workflow.SPWinOeHostServices.CreateInstance(SPWorkflow workflow) at Microsoft.SharePoint.Workflow.SPWinOeEngine.RunWorkflow(SPWorkflowHostService host, SPWorkflow workflow, Collection1 events, TimeSpan timeOut) at Microsoft.SharePoint.Workflow.SPWorkflowManager.RunWorkflowElev(SPWorkflow workflow, Collection1 events, S...

Any clues?

After much digging I found a workaround (which is suboptimal for me, btw):

  • Open the site in SPD 2010.

  • Navigate to "All files". Find the corresponding workflow XOML file, right-click on it and choose open as text.

  • On the top of the file there's a reference to the MyWorkflows.dll assembly version Change it to Save the file.

  • Open the workflow in the Workflow Editor. Save it and publish it.

After that the workflow works fine. However It would be hard to ask our clients to do that procedure for every single workflow they have.

I hope anybody out there can help me figure out how to make the assembly redirection work correctly in this case.

3 Answers 3


Never tried this with SharePoint Workflows, but any assembly redirections that you add to the web.config are not picked up by workflows running in owstimer, which is a different process.

You will need to create a config file in the owstimer directory for these redirections if such a file doesn't already exist.

  • I had tried that too, without success. As I am manually starting the workflow, it should be run in the W3WP process. This is confirmed by the fact the line in the ULS log containing the error contains W3WP.exe in it.
    – Anonymous
    Sep 13, 2010 at 6:24
  • Why don't you version the DLL that holds the SP2010 call as well? I assume you don't need both once on SP2010 Sep 13, 2010 at 9:36
  • That's definitely a solution, but one that my company is not willing to do. We might have to do that, though, if we don't find another way.
    – Anonymous
    Sep 28, 2010 at 11:20

Assembly redirection doesn’t work for workflows. Workflows runs in the timerjobs, assembly redirection is configured in the web.config.

Best regards

Rodrigo Pinto, SharePoint Specialist,Evangelist SharePointPt Founder www.sharepointpt.org @scoutmanpt


You could try deploying a publisher policy to perform the redirection at a higher level than the web.config

How to create a publisher policy

An IISRESET after it is added to the GAC might be necessary to re-evaluate the publisher policy.

  • Didn't work either. That's all very weird.
    – Anonymous
    Sep 28, 2010 at 11:19

Your Answer

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