处置IActivationBlock并导入IKernel时出错

Question

当我尝试使用下面的解决方案将Ninject 3与MVC 4 RC Web Api项目一起使用时,问题就出现了:

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

此解决方案使用IActivationBlock(使用IKernel中的BeginBlock方法创建)来实现调用范围.使用常规Ninject项目,似乎工作正常,但是当项目使用扩展Ninject.Extensions.Interception.DynamicProxy时,调用激活块的Dispose方法时会发生以下异常:

加载Ninject组件IAdviceRegistry时出错

没有这样的组件已在内核的组件容器中注册.

并且,在下一次创建新的ActivationBlock并调用Resolve方法时,会发生以下异常:

加载Ninject组件ICache时出错

没有这样的组件已在内核的组件容器中注册.

似乎问题与MVC更新没有直接关系,但是DynamicProxy和IActivationBlock之间存在一些不兼容性.

编辑:

问题的根源是,其中一个类型在构造函数上需要IKernel,并且它与DynamicProxy没有直接关系,但第一个异常仅在引用此程序集时发生.

因此,如果您的类型需要IKernel,则总会出现第二个错误(与ICache相关).

Answer 1

为了总结您的精彩分析：您在 ActivationBlock 内创建一个类的实例，该实例直接依赖于 IKernel。

这是一个逻辑缺陷，因为 ActivationBlock 的想法是在块被释放后“恢复内核的状态”，并且实例可以访问内核并可以不可逆转地更改任何绑定。（是的，该实例可以是一个 IDisposable，它会在自身之后进行清理；那么就不存在逻辑缺陷——只是一个不寻常的用例）。

我的经验是，绝大多数这些用途都是调用 IKernel.Get<...>(...) 等。显然，这在 ActivationBlock 内是有效的：您只是请求了超出您需要的内容：IKernel 而不是 IResolutionRoot（例如，您不需要 IKernel 的 IBindingRoot）。改变你班级的类型，你就会没事的。

PS感谢您对异常来源的分析。它帮助我解决了我自己的问题。