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 时，调用激活 block 的 Dispose 方法时会出现以下异常:

Error loading Ninject component IAdviceRegistry

No such component has been registered in the kernel's component container.

并且，在下次创建新的 ActivationBlock 并调用 Resolve 方法时，会出现以下异常:

Error loading Ninject component ICache

No such component has been registered in the kernel's component container.

似乎问题与 MVC 更新没有直接关系，而是 DynamicProxy 和 IActivationBlock 之间的一些不兼容。
编辑:
问题的根源是当其中一种类型在构造函数上需要 IKernel 时，它与 DynamicProxy 没有直接关系，但第一个异常仅在您引用此程序集时发生。
因此，如果您的类型需要 IKernel，则总是会出现第二个错误(与 ICache 相关)。

Answer 1

总结一下你的分析:你在一个 ActivationBlock 中创建一个类的实例，它直接依赖于 IKernel。

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

我的经验是，绝大多数这些用途都是调用 IKernel.Get<...>(...) 和 friend 。显然，这在 ActivationBlock 中是有效的:您只是请求比您需要的更多:一个 IKernel 而不是 IResolutionRoot(例如，您不需要 IKernel 的 IBindingRoot)。改变你类(class)的类型，你会没事的。

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