我有一个这样的场景:
我使用拦截器来捕获对主项目引用的程序集中的类(我们称之为功能)的调用。程序集功能由 NuGet 安装(它不是公开的,而是我们的内部程序集),并引用另一个程序集(我们称之为 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 (...)
其中 Core 0.2.2.30 版本是程序集功能所期望的版本,主项目正在使用例如版本 0.2.2.31。 Castle DynamicProxy 无法找到版本 0.2.2.30 的 Core,这是正确的,因为这个确切的程序集未部署到 bin 文件夹。
请注意,在我们的场景中,不同版本的 Core 是完全正常的情况。功能组件期望的版本高于指定的版本 - 不是确切的版本。
我不确定 DynamicProxy 的装配期望是否应该不那么严格,因为我确实必须接受这个限制。我编写了简单的代理类来解决这个问题,因此它不再阻止我,但它阻止我们在解决方案中使用 DynamicProxy。
该问题是由于 DP 是针对已签名的程序集生成的,然后使用该程序集的未签名版本而引起的。
解决方案是确保在这两种情况下都使用签名的程序集,或者强制 DynamicProxy 仅生成未签名的程序集。
本文内容由网友自发贡献,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系:hwhale#tublm.com(使用前将#替换为@)