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

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


@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. :-) )

链接地址: http://www.djcxy.com/p/95856.html

上一篇: 如何暂停工作流(声明式服务库)服务?

下一篇: 使用代码库/探测路径在不同路径上组装Workflow Foundation 4