2012-06-26 12 views
6

El problema comenzó cuando yo estaba tratando de usar la solución a continuación para utilizar Ninject 3 con un MVC 4 RC proyecto Web API:error al desechar una IActivationBlock e importación iKernel

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

Esta solución utiliza IActivationBlock (creado con el método BeginBlock de IKernel) para implementar el alcance de las llamadas. Con un proyecto normal Ninject, parece funcionar bien, pero cuando el proyecto utiliza la extensión Ninject.Extensions.Interception.DynamicProxy, la siguiente excepción se produce cuando se llama al método Dispose del bloque de activación:

Error al cargar el componente Ninject IAdviceRegistry

No se ha registrado ningún componente en el contenedor de componentes del kernel.

Y, en la próxima vez cuando se crea un nuevo ActivationBlock y el método Resolve se llama, produce la excepción siguiente:

Error al cargar Ninject componente iCache

No existe el componente ha sido registrado en el contenedor de componentes del kernel.

Parece que el problema no está directamente relacionado con la actualización de MVC, sino con alguna incompatibilidad entre DynamicProxy y IActivationBlock.

Editar:

El origen del problema es cuando uno de los tipos requiere iKernel en el constructor, y no es directamente relacionado con DynamicProxy, pero la primera excepción sólo se produce cuando las referencias a esta asamblea.

Entonces, el segundo error (relacionado con ICache) siempre ocurre si su tipo requiere IKernel.

+0

Estoy viendo esto también –

+0

¿Alguien alguna vez encuentra un workarround? – dtabuenc

Respuesta

0

Para summerize su buen análisis: crea una instancia de una clase dentro de un ActivationBlock que tiene dependencia en el IKernel directamente.

Esto es un error lógico, ya que la idea de un ActivationBlock es "restaurar el estado" del kernel después de que se elimine el bloque y una instancia que tenga acceso al núcleo y pueda cambiar irreveblemente cualquiera de los enlaces. (Sí, la instancia podría ser un IDisposable que se limpia después de su auto, entonces no hay un error lógico, solo un caso de uso inusual).

Mi experiencia es que la gran mayoría de estos usos son para llamar a IKernel.Obtener < ...> (...) y amigos. Obviamente esto es válido dentro de un ActivationBlock: solo está solicitando más de lo que necesita: un IKernel en lugar de IResolutionRoot (por ejemplo, no necesita IBindingRoot de IKernel). Cambia los tipos en tu clase y estarás bien.

P.S. Gracias por su análisis de la fuente de la excepción. Me ayudó con mi propio problema.

Cuestiones relacionadas