Workflow Foundation 4 assembly in different path using codebase / probing path

Question

We have a long running workflow implemented using WF4 workflow services. We presently have a problem that when a new version of the workflow is deployed, existing persisted instances don't get loaded up. I saw on How do you manage versions in Workflow Foundation? (which then led to http://msmvps.com/blogs/theproblemsolver/archive/2008/09/10/versioning-long-running-workfows.aspx?ocid=aff-n-we-loc--DEV40909&WT.mc_id=aff-n-we-loc--DEV40909) on managing different versions using the codebase href hint in the app.config.

This works for a simple workflow that doesn't have any custom code activities - I deployed the XAMLX in an IIS 7 application, created a sub-directory (bin/v1) and put the DLLs there, and specified the probe path as below:

<runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
        <probing privatePath="v1" />
        <probing privatePath="bin/v1" /> <!-- one of these is probably redundant... -->
    </assemblyBinding>
</runtime>

However, when I add a custom code activity, the XAMLX appears to have a reference to the assembly like the following (I have excluded the standard assemblies from this):

<WorkflowService mc:Ignorable="sap sads" ConfigurationName="Service1"
sap:VirtualizedContainerService.HintSize="307,436" Name="Service1"
mva:VisualBasic.Settings="Assembly references and imported namespaces serialized as XML namespaces"
xmlns="http://schemas.microsoft.com/netfx/2009/xaml/servicemodel"
xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
...
xmlns:p1="http://schemas.microsoft.com/netfx/2009/xaml/activities"
**xmlns:p2="clr-namespace:PromotionWorkflowV1;assembly=PromotionWorkflowV1"**
xmlns:s="clr-namespace:System;assembly=mscorlib"
...
>

When I try and navigate to the WF service in a browser, I get a parser error like:

Cannot create unknown type '{clr-namespace:PromotionWorkflowV1;assembly=PromotionWorkflowV1}SubmitActivity'.' Line number '42' and line position '6'.

I am presuming that this is because WF doesn't look at the probing path while it is parsing the XAMLX? Is there something else that can be done so I can achieve versioning in this scenario?

Thanks, -Srinivas

I subsequently found that registering the assembly in the GAC works, so while I can get by using this, the probing path / codebase hint would be a simpler thing from a deployment perspective. — Srinivas
"specified the probe path as below". Something is missing on your question. How have you specified the probe path? — Joao
I've just noticed that the blog links you provided are targeted for a WF vesion prior to 4 which isn't at all the same as WF4. Are you aware that since NET 4.5 workflow foundation provides an out-of-the-box versioning mechanism? Check this. — Joao
I am presuming Well, that's your first problem. Do not "presume", instead determine what is happening by using the Fusion log viewer. Just make sure to run it as admin, turn on the log, and reboot before attempting to debug. You'll see where the CLR is looking for the assembly, and what version, and from there determine why it isn't being found (if you even have it installed). — user1228
Thanks, @Jota. The probing path was as follows (removed XML tags): runtime assemblyBinding xmlns="..." probing privatePath="v1" probing privatePath="bin/v1" Without custom code activities, this works - the DLLs are being picked up ok, so the probing path is ok. This is a legacy app though, so can't move to .Net 4.5 right now. Will, I did try fuslogvw as administrator, but that didn't show up this particular bind failure (I had set this to log both successful and failure binds) so I considered that this was even before the call to bind. I will check on that again. Thanks! — Srinivas

Srinivas Srinivas · Accepted Answer · 2014-01-09T08:53:18

@Will, I did an iisreset and was able to capture this bind as well. Thanks!

I relooked at fuslogvw logs, and it turns out that the issue was the way I was specifying the probing paths. The following:

<probing privatePath="v2" />
<probing privatePath="bin/v2" />

only honors the first path, and not the second. The first didn't succeed, since that was considered to be from the root of the web app, and the second wasn't looked at.

When I removed the first path, the bind was successful. The other option of specifying multiple paths per the MSDN documentation is:

<probing privatePath="v2;bin/v2" />

I also found that having a space after the ";" also doesn't work, since the space is also used in the path, so this became "D:/myDir/ bin/v2").

One observation was that the XAMLX file has only the assembly name, and not the version. I manually edited it to specify the version number as well, and now this picks up the correct DLL version as well.

Thanks for your help! (Plus the reminder to not presume, and to read the documentation a little more carefully. :-) )

Workflow Foundation 4 assembly in different path using codebase / probing path

1 Answers