Castle DynamicProxy Interceptor具有不同程序集的问题

Daw*_*ski 5 c# castle-dynamicproxy

我有这样的场景:

我正在使用拦截器来捕获对主程序引用的程序集内部类(我们称之为Feature)的类的调用.装配特征由NuGet安装(它不是公共的,而是我们的内部装配)并且引用了另一个装配(让我们称之为Core).主项目也引用了汇编Core.Core包含类定义,该类定义用作截取方法之一的参数类型.

只要主项目和功能引用相同版本的Core库,一切正常.当此版本不同并且截获的方法使用Core中的类型作为方法参数时出现问题.

在这种情况下,会抛出一个异常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 (...)
Run Code Online (Sandbox Code Playgroud)

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.

Krz*_*mic 7

问题是由于DP是针对已签名的程序集生成的,然后正在使用未签名的程序集版本.

解决方案是确保在两种情况下都使用带符号的程序集,或强制DynamicProxy仅生成无符号程序集.

  • 找到它:) windsorContainer.Kernel.ProxyFactory = new DefaultProxyFactory(disableSignedModule:true); (6认同)