ninject - 处理 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 感谢您对异常来源的分析。它帮助我解决了我自己的问题。