Castle DynamicProxy Interceptor having problems with different assemblies

Question

I have a scenario like this:

I'm using interceptor to catch calls to a class that is inside assembly (let's call it Feature) that is referenced by main project. Assembly Feature is installed by NuGet (it's not public but our internal one) and has reference to another assembly (let's call it Core). Main project is referencing assembly Core as well. Core contains class definition that is used as an argument type of one of the intercepted methods.

It all works fine as long as Main project and Feature are referencing the same version of Core library. Problem arises when this versions are different and intercepted method uses types from Core as a method arguments.

In this situation, an exception is thrown that states A strongly-named assembly is required.:

[FileLoadException: Could not load file or assembly 'Core, Version=0.2.2.30, Culture=neutral, PublicKeyToken=null' or one of its dependencies. A strongly-named assembly is required. (Exception from HRESULT: 0x80131044)] 
 Castle.Proxies.Invocations.IBasketService_Update.InvokeMethodOnTarget() +0
 Castle.DynamicProxy.AbstractInvocation.Proceed() +116
 Project.Basket.BasketServiceUpdatedInterceptor.Intercept(IInvocation invocation) in c:\(...)\Basket\BasketServiceUpdatedInterceptor.cs:20
 Castle.DynamicProxy.AbstractInvocation.Proceed() +604
 Castle.Proxies.IBasketServiceProxy.Update(ProductId productId, UInt16 quantity) +210 (...)

Where version of Core 0.2.2.30 is a version that assembly Feature is expecting, main project is using for example version 0.2.2.31. Castle DynamicProxy is not able to find Core with version 0.2.2.30 and that's right because this exact assembly is not deployed to bin folder.

Please note that different versions of Core are a situation perfectly normal in our scenario. Feature assembly is expecting version higher than specified - not exact version.

I'm not sure whether DynamicProxy should be less rigid in it's assembly expectations are I do have to accept this limitation. I've written simple proxy class to overcome this problem so it does not block me anymore yet it blocks us from using DynamicProxy in our solutions.

Answer 1

The problem is caused by the fact that DP was generated against a signed assembly and then an unsigned version of the assembly is being used.

The solution is either to ensure that you use signed assembly in both cases, or to force DynamicProxy to only generate unsigned assembly.