Side by side versioning of Windows workflow 4.5- how to load correct versions of business dll

Question

I have hosted two versions of workflow (WF 4.5). Followed the instructions as in this MSDN sample- https://code.msdn.microsoft.com/windowsapps/Side-by-Side-Versioning-0fe24cd3. The side-by-side functionality provided allows a workflow service to be configured so that new instances of the workflow service are created using the new workflow definition, while running instances complete using the existing definition.

Workflow (xamlx) makes use of few functions that are defined in another class library 'MessageGeneration.dll'. There are changes in those functions as well. So, there are two versions of both workflow and MessageGeneration.dll. WF-v1 should use MessageGeneration.dll-v1 and WF-v2 should use MessageGeneration.dll-v2.

Any suggestions to solve this will be helpful. Thanks.

Answer 1

I am not familiar with how WF processes work, however following approach generally works in this kind of scenarios:

You can specify binary location for specific version on the config file (app.config/web.config) which is the place CLR look for while resolving a binary. General info on CodeBase.

Here is an example:

<dependentAssembly>
            <assemblyIdentity name="assembly name" publicKeyToken="token" culture="neutral" />
            <codeBase version="specific version" href="bin/binary.dll" />
            <codeBase version="specific version" href="bin/subBin/binary.dll" />
        </dependentAssembly>

here, binary.dll under subBin is v2 of the binary in question. Now, for this to work, WF should not try to instantiate both binaries together. That can be handled by removing any public code paths which look for this binary. You could probably call methods on the above binaries using a factory which will have methods marked as internal so that when WF process instantiates, binary.dll is not loaded.

It would fail to load binary as the codebase href would be wrong. Use Procmon to see which locations are probed for loading the binary. Based on the procmon report, either the path on the config can be fixed or the binary can be binplaced.