我有一个依赖于其他程序集的 Azure 函数，而其他程序集又依赖于 Ninject 进行依赖注入。在运行时，Ninject 似乎无法解析某些 custom 的依赖关系Ninject.Activation.Provider<T>，从而导致System.IO.FileNotFoundException.
堆栈跟踪的 Ninject 部分是：
在 Ninject.Activation.Provider`1.Create(IContext context) at Ninject.Activation.Context.ResolveInternal(Object scope) at Ninject.Activation.Context.Resolve() at Ninject.KernelBase.<>c__DisplayClass15.b__f(IBinding binding)在 System.Linq.Enumerable.WhereSelectEnumerableIterator`2.MoveNext() 在 System.Linq.Enumerable.SingleOrDefault[TSource](IEnumerable`1 源) 在 Ninject.Planning.Targets.Target`1.GetValue(Type service,IContext parent)在 Ninject.Planning.Targets.Target`1.ResolveWithin(IContext parent) 在 Ninject.Activation.Providers.StandardProvider.GetValue(IContext context,ITarget 目标) 在 Ninject.Activation.Providers.StandardProvider.<>c__DisplayClass4.b__2(ITarget 目标) 在 System.Linq.Enumerable.WhereSelectArrayIterator`2.MoveNext() 在 System.Linq.Buffer`1..ctor(IEnumerable`1 source) at System.Linq.Enumerable.ToArray[TSource](IEnumerable`1 source) at Ninject.Activation.Providers.StandardProvider.Create(IContext context) at Ninject.Activation.Context.ResolveInternal(O…< /p>
未解决的依赖项是 to System.Web.Mvc, Version=5.1.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35（或其依赖项之一）。它通过 NuGet 包含在项目中。
然而，这个有问题的程序集确实存在于磁盘上 Azure Function 的 bin 文件夹中，并且构建本身很好。因此，我的理论是 Ninject 在实例化 custom 时做了一些特殊的事情Provider<T>。
也许 Ninject 期望将依赖项收集在另一个位置，相对于函数执行的位置或其他什么？也许根本不是 Ninject 应该受到指责的，而是在我不知道的 Azure 环境中如何解决依赖关系方面的一些特殊情况？
我希望你们中的某个人可以通过阐明这里发生的事情来帮助我，或者建议采取明智的故障排除措施，因为我已经把所有的空白都画了几天了。
如果是这种情况，我可以影响负责自定义的人员如何Provider<T>在他们的代码中解决问题，因此可能的解决方案包括这个场所。
预先感谢您！