Azure ServiceBus to MSMQ Service Control Adapter

I have a new endpoint that we setup using Azure ServiceBus to PoC using it as a transport. The vast majority of our endpoints are running internally using MSMQ which is also how our internal Service control instance is setup using MSMQ. I am trying to get the service control transport adapter to be able to pull the heartbeat/custom checks, audit and failure messages from Azure ServiceBus over to our MSMQ service control instance so that everything is centralized. Currently when I run the transport adapter solution I am getting the following error:

System.AggregateException: One or more errors occurred. ---> System.IO.FileLoadException: Could not load file or assembly 'System.Threading.Tasks.Extensions, Version=4.2.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
   at NServiceBus.Transport.AzureServiceBus.MessageSenderPool..ctor(String connectionString, TokenCredential tokenCredential, ServiceBusRetryOptions retryOptions, ServiceBusTransportType transportType, TransportTransactionMode transactionMode)
   at NServiceBus.Transport.AzureServiceBus.AzureServiceBusTransportInfrastructure.CreateMessageDispatcher()
   at NServiceBus.Raw.InitializableRawEndpoint.<Initialize>d__1.MoveNext()

This is the code I have setup for the transport adapter:

 public async Task Start(IMessageSession session)
        {

            var transportAdapterConfig = new TransportAdapterConfig<AzureServiceBusTransport, MsmqTransport>($"{System.Reflection.Assembly.GetExecutingAssembly().GetName().Name}.ASB.Adapter");
            var msmqServiceControlServerName = ConfigurationManager.AppSettings["MSMQServiceControlServerName"];
            var msmqServiceControlInstanceName = ConfigurationManager.AppSettings["MSMQServiceControlInstanceName"];

            transportAdapterConfig.CustomizeEndpointTransport
                (
                    customization: transport =>
                    {
                        transport.ConnectionString($"{ConfigurationManager.ConnectionStrings["AzureServiceBusTransportConnectionString"].ConnectionString}");
                        transport.Transactions(TransportTransactionMode.ReceiveOnly);

                    }
                );

            transportAdapterConfig.EndpointSideControlQueue = "Particular.Servicecontrol.ASB";

            transportAdapterConfig.ServiceControlSideControlQueue = msmqServiceControlInstanceName;

            if (!string.IsNullOrEmpty(msmqServiceControlServerName))
            {
                transportAdapterConfig.ServiceControlSideAuditQueue = $"audit@{msmqServiceControlServerName}";
                transportAdapterConfig.ServiceControlSideErrorQueue = $"error@{msmqServiceControlServerName}";
                transportAdapterConfig.ServiceControlSideControlQueue = $"{msmqServiceControlInstanceName}@{msmqServiceControlServerName}";
            }

            _adapter = TransportAdapter.Create(transportAdapterConfig);


            await _adapter.Start().ConfigureAwait(false);
        }

I was wondering if there was something I am missing or what I’m doing wrong here

Packages:

  1. NServiceBus 7.2.5
  2. NServiceBus.Host 8.0.0
  3. NServiceBus.Transport.AzureServiceBus 2.0.2
  4. NServiceBus.Transport.MSMQ 1.2.0
  5. ServiceControl.TransportAdapter 2.0.1
  6. .NetFramework 4.7.2

Hi Mick,

The stacktrace suggests it is an issue of assembly version mismatch. Did you try to set a binding redirect to see if that resolves it?

I have tried adding the binding redirects but continued to get the error shown above. I’ve also attempted to add that specific version of the package directly into my solution as well with no luck either. I have also never seen this thrown/logged for a binding error and this part of the log is in a different format than my other NLog logs:

=== Pre-bind state information ===
LOG: DisplayName = System.Threading.Tasks.Extensions, Version=4.2.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51
 (Fully-specified)
LOG: Appbase = file:///C:/Git/SCAdapter/src/Endpoints.ServiceControlAdapter/Endpoints.ServiceControlAdapter/bin/Debug/
LOG: Initial PrivatePath = NULL
Calling assembly : Microsoft.Bcl.AsyncInterfaces, Version=1.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51.
===
LOG: This bind starts in default load context.
LOG: Using application configuration file: C:\Git\SCAdapter\src\Endpoints.ServiceControlAdapter\Endpoints.ServiceControlAdapter\bin\Debug\mwa.ITOps.TPI.NSB.Endpoints.ServiceControlAdapter.dll.config
LOG: Using host configuration file: 
LOG: Using machine configuration file from C:\Windows\Microsoft.NET\Framework64\v4.0.30319\config\machine.config.
LOG: Post-policy reference: System.Threading.Tasks.Extensions, Version=4.2.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51
LOG: Attempting download of new URL file:///C:/Git/SCAdapter/src/Endpoints.ServiceControlAdapter/Endpoints.ServiceControlAdapter/bin/Debug/System.Threading.Tasks.Extensions.DLL.
WRN: Comparing the assembly name resulted in the mismatch: Revision Number
ERR: Failed to complete setup of assembly (hr = 0x80131040). Probing terminated.

I figured out the issue is the version that was being written to the logs for the binding redirect wasn’t actually what needed to be set. Had to go into the different dll’s to get the correct version number

Hi Mick,
I have similar problem referencing Azure.Messaging.EventHubs.
Getting:

System.IO.FileLoadException: Could not load file or assembly ‘System.Threading.Tasks.Extensions, Version=4.2.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51’ or one of its dependencies. The located assembly’s manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
File name: ‘System.Threading.Tasks.Extensions, Version=4.2.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51’

I have tried similar solutions with assembly binding…with no use.

Can you elaborate on what solved this problem for you?

It has been awhile so I’m trying to remember what I did to fix this. I believe I had to a use a tool like ILSpy or dnSpy to look at the dlls to figure out the correct version to add to the binding redirect. What was being written out to the log for the version number wasn’t correct in my case