处理 IActivationBlock 和导入 IKernel 时出错答案

【问题标题】：Error when disposing a IActivationBlock and importing IKernel处理 IActivationBlock 和导入 IKernel 时出错
【发布时间】：2012-06-28 05:54:42
【问题描述】：

当我尝试使用下面的解决方案将 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 相关）。

【问题讨论】：

有人想出解决办法吗？

标签： ninject asp.net-mvc-4 asp.net-web-api

【解决方案1】：

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

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

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

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

【讨论】：