Castello DynamicProxy Interceptor hanno problemi con diverse assemblee

Question

Ho uno scenario come questo:

sto usando intercettore per prendere le chiamate a una classe che è il montaggio all'interno (chiamiamolo Feature) a cui fa riferimento principale del progetto. Assembly Feature è installato da NuGet (non è pubblico ma è il nostro interno) e fa riferimento a un altro assembly (chiamiamolo Core). Il progetto principale si riferisce anche al nucleo di assemblaggio. Core contiene una definizione di classe che viene utilizzata come tipo di argomento di uno dei metodi intercettati.

Funziona tutto bene finché il progetto principale e la caratteristica fanno riferimento alla stessa versione della libreria Core. Il problema sorge quando queste versioni sono diverse e il metodo intercettato utilizza i tipi di Core come argomenti del metodo.

In questa situazione, viene generata un'eccezione che gli stati 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 (...) 

Dove versione del Nucleo 0.2.2.30 è una versione che Feature assemblaggio si aspetta, progetto principale sta usando per esempio la versione 0.2.2.31. Castle DynamicProxy non è in grado di trovare Core con la versione 0.2.2.30 ed è giusto perché questo assembly esatto non è distribuito nella cartella bin.

Si prega di notare che diverse versioni di Core sono una situazione perfettamente normale nel nostro scenario. L'assembly delle funzioni prevede una versione superiore a quella specificata, non una versione esatta.

Non sono sicuro che DynamicProxy debba essere meno rigido nelle sue aspettative di assemblaggio. Devo accettare questa limitazione. Ho scritto una semplice classe proxy per superare questo problema, quindi non mi blocca più, ma ci impedisce di utilizzare DynamicProxy nelle nostre soluzioni.

Answer 1

Il problema è causato dal fatto che DP è stato generato rispetto a un assembly firmato e quindi viene utilizzata una versione non firmata dell'assieme.

La soluzione consente di utilizzare assembly firmato in entrambi i casi o di forzare DynamicProxy a generare solo assembly non firmati.