Which assembly is trying to load this specific version of Microsoft.ServiceBus?

Looking for some stacktrace reading pointers here:

[FileLoadException: Could not load file or assembly 'Microsoft.ServiceBus, Version=2.1.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)]
   System.Reflection.RuntimeAssembly.GetExportedTypes(RuntimeAssembly assembly, ObjectHandleOnStack retTypes) +0
   System.Reflection.RuntimeAssembly.GetExportedTypes() +32
   Castle.Core.Internal.ReflectionUtil.GetAvailableTypes(Assembly assembly, Boolean includeNonExported) +46
   Castle.Core.Internal.ReflectionUtil.GetAvailableTypesOrdered(Assembly assembly, Boolean includeNonExported) +15
   System.Linq.<SelectManyIterator>d__17`2.MoveNext() +529
   Castle.MicroKernel.Registration.FromDescriptor.Castle.MicroKernel.Registration.IRegistration.Register(IKernelInternal kernel) +334
   Castle.MicroKernel.DefaultKernel.Register(IRegistration[] registrations) +72
   Castle.Windsor.WindsorContainer.Register(IRegistration[] registrations) +49
   Shopify.Common.DI.DI.BootstrapContainer(Assembly webAssembly) in C:\Users\tomcat\.jenkins\workspace\Shopify\Test Shopify.AdminPortal.Web\src\Shopify\Shopify.Common.DI\DI.cs:49
   Shopify.AdminPortal.Web.DI.DependencyRegistrar.Register() in C:\Users\tomcat\.jenkins\workspace\Shopify\Test Shopify.AdminPortal.Web\src\Shopify\Shopify.AdminPortal.Web\DI\DependencyRegistrar.cs:25
   Shopify.AdminPortal.Web.MvcApplication.Application_Start() in C:\Users\tomcat\.jenkins\workspace\Shopify\Test Shopify.AdminPortal.Web\src\Shopify\Shopify.AdminPortal.Web\Global.asax.cs:23

[HttpException (0x80004005): Could not load file or assembly 'Microsoft.ServiceBus, Version=2.1.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)]
   System.Web.HttpApplicationFactory.EnsureAppStartCalledForIntegratedMode(HttpContext context, HttpApplication app) +546
   System.Web.HttpApplication.RegisterEventSubscriptionsWithIIS(IntPtr appContext, HttpContext context, MethodInfo[] handlers) +171
   System.Web.HttpApplication.InitSpecial(HttpApplicationState state, MethodInfo[] handlers, IntPtr appContext, HttpContext context) +173
   System.Web.HttpApplicationFactory.GetSpecialApplicationInstance(IntPtr appContext, HttpContext context) +255
   System.Web.Hosting.PipelineRuntime.InitializeApplication(IntPtr appContext) +347

[HttpException (0x80004005): Could not load file or assembly 'Microsoft.ServiceBus, Version=2.1.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)]
   System.Web.HttpRuntime.FirstRequestInit(HttpContext context) +552
   System.Web.HttpRuntime.EnsureFirstRequestInit(HttpContext context) +122
   System.Web.HttpRuntime.ProcessRequestNotificationPrivate(IIS7WorkerRequest wr, HttpContext context) +737
   

I ask because I'm slightly confused about the versioning. The two projects mentioned here Shopify.Common.DI and Shopify.AdminPortal.Web have a nuget package reference to WindowsAzure.ServiceBus nuget package v6.0.4, which apparently causes v3.0.0.0 of Microsoft.ServiceBus.dll to be deposited on disk. Neither of these projects mentions v2.1.0.0, and the stack trace to me seems to imply that it is CastleWindsor that is causing the runtime to look for 2.1 (and I assume, find 3.0 - can't confirm exactly which one is being found on Azure because I don't know how to enable binding logging, but I do know that hte only Microsoft.ServiceBus.dll in the site folder on the azure machine, is v3.0).

Is it CastleWindsor looking for this specific version? And what would a DI/IOC library want with it? Or is it that CW is trying to load some other assembly*, that does have a reference to 2.1 - and if so, the stacktrace isn't recording all the info as to what assembly is actually being tried/logging which one would be CW's job/problem and the stacktrace will never contain this info?