Recently, I had a full load of workflows (WF 3.5) already in production. I made some changes to the workflow definitions (something I did many times before), but this time was definitely different:

Although I added old workflows to the app.config file like this:

<!--
  Support old workflows     
    Needs to be updated when the workflow definitions change  
-->    
<dependentAssembly>    
  <assemblyIdentity name="MyProject.WorkflowFoundation.Workflows" publicKeyToken="1aaf4ff5851673aa" />    
  <codeBase version="1.0.0.0" href="WorkflowCompatibility/MyProject.WorkflowFoundation.Workflows.1.0.0.0.dll" />    
  <codeBase version="2.0.0.0" href="WorkflowCompatibility/MyProject.WorkflowFoundation.Workflows.2.0.0.0.dll" />    
</dependentAssembly>

I was unable to load the workflows created before. I got the following error:

“System.Runtime.Serialization.SerializationException: Cannot get the member '<Initialize>b__0'.”

What seems: when you update the implementation of a custom activity (even if the outside interface does not change), you need to increase the version of the assembly that defines the custom activity, in my case MyProject.WorkflowFoundation. Then, you need to relocate the right version to the right assembly in your app.config:

<!--    
  Support old workflow activities     
    Needs to be updated when the interfaces for an activity change    
-->    
<dependentAssembly>    
  <assemblyIdentity name="MyProject.WorkflowFoundation" publicKeyToken="1aaf4ff5851673aa" />    
  <codeBase version="1.0.0.0" href="WorkflowCompatibility/MyProject.WorkflowFoundation.1.0.0.0.dll" />    
</dependentAssembly>

So remember, you should not only strong name your assembly and version it correctly, you should also strong name the assembly containing your custom services and activities.

Last update:

the thing I changed in the activity was that I no longer subscribed to the StatusChanged event, which seems innocent in the first place. But probably, the event is not decorated with the [field:NonSerialized] attribute.

I finally got the opportunity to work with WF (Workflow Foundation) in a real-life situation. For one of my clients, I have implemented an application that supports workflows. Since I knew that the existing workflow system we used was overpriced and did too little for the too much being paid, I recommended to use WF. The software I developed already used providers so it was easy to write a new “workflow provider” for WF (and still be able to use the old system as well).

After some investigation, the client agreed to go ahead with WF, and it all seems to work perfectly now (so a happy me and a happy client). However, below are some things I noticed during the integration of WF.

Workflow and its activities not fully recognized

I wrote a proof of concept for the client so they could see that WF fits their needs. This POC worked perfectly. However, when porting the code to the final software, I was not able to create workflows successfully. When investigating the persistence database, I noticed that only the top-level activity was persisted (and the activity was closed immediately).

After searching for a few hours, I decided the only difference was that the workflow definition was located in a separate assembly in my POC. When I moved the workflow definition to a separate assembly, it all seemed to work perfect (workflow including its activities were fully recognized).

I will add more things I stumbled upon soon.