2012-06-26 14 views
6

Il problema è iniziato quando stavo cercando di utilizzare la soluzione qui di seguito per utilizzare Ninject 3 con un RC progetto Web Api MVC 4:errore quando lo smaltimento di un IActivationBlock e l'importazione Ikernel

http://www.peterprovost.org/blog/2012/06/19/adding-ninject-to-web-api/

Questa soluzione utilizza IActivationBlock (creato con il metodo BeginBlock da IKernel) per implementare l'ambito delle chiamate. Con un normale progetto Ninject, sembra funzionare bene, ma quando il progetto utilizza l'estensione Ninject.Extensions.Interception.DynamicProxy, la seguente eccezione si verifica quando il metodo Dispose blocco di attivazione è chiamato:

Errore caricamento componente Ninject IAdviceRegistry

Nessun componente è stato registrato nel contenitore del componente del kernel.

E, la prossima volta quando viene creata una nuova ActivationBlock e il metodo Resolve viene chiamato, la seguente eccezione si è verificato:

Errore durante il caricamento Ninject componente Icache

Nessun tale componente è stato registrato nel contenitore del componente del kernel.

Sembra che il problema non sia direttamente correlato all'aggiornamento MVC, ma qualche incompatibilità tra DynamicProxy e IActivationBlock.

Edit:

La fonte del problema è quando uno dei tipi richiede Ikernel sul costruttore, e non è direttamente legato alla DynamicProxy, ma la prima eccezione si verifica solo quando si fa riferimento a questa assemblea.

Quindi, il secondo errore (correlato a ICache) si verifica sempre se il tuo tipo richiede IKernel.

+0

Sto vedendo anche questo –

+0

Qualcuno capisce mai un workarround? – dtabuenc

risposta

0

Per estendere la tua bella analisi: si crea un'istanza di una classe all'interno di un ActivationBlock che ha dipendenza direttamente da IKernel.

Questo è un difetto logico, poiché l'idea di un ActivationBlock è di "ripristinare lo stato" del kernel dopo che il blocco è stato disposto e un'istanza che ha accesso al kernel e può cambiare in modo non reversibile qualsiasi legame. (Sì, l'istanza potrebbe essere un IDisposable che pulisce dopo se stesso, quindi non vi è alcun difetto logico - solo un caso d'uso insolito).

La mia esperienza è che la stragrande maggioranza di questi usi è chiamare IKernel.Get < ...> (...) e amici. Ovviamente questo è valido all'interno di ActivationBlock: stai solo richiedendo più del necessario: un IKernel invece di IResolutionRoot (ad esempio non hai bisogno di IBindingRoot di IKernel). Cambia i tipi nella tua classe e starai bene.

P.S. Grazie per la tua analisi per la fonte dell'eccezione. Mi ha aiutato con il mio problema.

Problemi correlati