Introduction
When using the Web Platform Installer to download and/or install Workflow Manager you can no longer download and install Workflow Manager 1.0 and Workflow Manager 1.0 CU1. The only option is to download Workflow Manager 1.0 Refresh (which essentially is CU2). So when installing a new Workflow Manager farm for SharePoint or just because you want to rock some workflows you have to use Workflow Manager (WFM) 1.0 Refresh. Unless you’ve been smart and previously downloaded and saved the original Workflow Manager. When using WFM 1.0 Refresh you also need to download Service Bus 1.1.
Trouble in paradise!
Installing the bits works like a charm and if you configure the Workflow Manager farm and the Service Bus using the wizard everything is golden. But if you’re a real professional then you of course use a scripted and repeatable approach and use PowerShell to build out your Workflow Manager farm.
Most of the PowerShell commands and steps works as expected when creating the Service Bus farm, the Workflow Manager Farm, adding the first Service Bus host and creating the Service Bus namespace. But when you try to add a Workflow Host to the machine, using the Add-WFHost cmdlet, and when it tries to connect to the Service Bus namespace you get an error like this:
Add-WFHost : Cannot validate argument on parameter 'SBClientConfiguration'.
Could not load file or assembly
'Microsoft.ServiceBus, Version=1.8.0.0, Culture=neutral,
PublicKeyToken=31bf3856ad364e35' or one of its dependencies.
The system cannot find the file specified.
If we crack up the Microsoft.Workflow.Deployment.Commands.dll using our favorite tool of choice of disassembly we can see that it actually references version 1.8.0.0 of Microsoft.ServiceBus.dll. Obviously a bug in this release!
Solve the problem using basic .NET features
The easiest way to work around it is of course to use the wizard, which works, but that is for slackers. So let’s instead use some basic .NET framework knowledge and make an assembly redirection. Assembly redirection is a way to redirect one version of an assembly to another, so that when the .NET framework tries to load version 1.8.0.0 we ask it to load version 2.1.0.0 (which is the Service Bus 1.1 version number). There is a couple of ways to do this;
- We can update the machine.config file and make a machine wide redirection – I do not recommend this approach for obvious reasons
- We can update the PowerShell.exe.config file and make the redirection for all PowerShell sessions – not a good approach either
- Or we can dynamically load the configuration data in our PowerShell session – Heureka, that’s the way to do it!
In order to do the assembly redirection we need to create a .config file which tells the .NET framework how to do the redirection. This is how the .config file should look like, and in this case I named it wfm.config. If you want do dig deeper into Assembly Redirection there is of course documentation on MSDN.
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="Microsoft.ServiceBus"
publicKeyToken="31bf3856ad364e35"
culture="en-us" />
<bindingRedirect oldVersion="1.8.0.0" newVersion="2.1.0.0" />
</dependentAssembly>
</assemblyBinding>
</runtime>
</configuration>
To load this configuration into the current AppDomain we use the SetData() method of the current AppDomain and pass in the path to the file like this:
$filename = Resolve-Path .\wfm.config
[System.AppDomain]::CurrentDomain.SetData("APP_CONFIG_FILE", $filename.Path)
As you can see from above, we create a variable with the path to the .config file and then grab the current AppDomain and invoke the SetData() method with the APP_CONFIG_FILE key and the filename as value.
Once you have created the file and executed those two lines of PowerShell you can use the Add-WFHost once again and continue your Workflow Manager configuration.
Summary
In this post you’ve seen a (major) issue with the Workflow Manager 1.0 Refresh, where you cannot add new Workflow Hosts to your Workflow Manager farm, due to an invalid assembly reference. Using “basic” .NET framework knowledge we can “fix” this issue by using assembly redirection. Hopefully someone from the WFM team will pick this up and make a refresh of the refresh.