可重用类库内部的依赖注入（DI）

我有一组项目，这些项目提供运行.Net服务所需的所有功能。该项目通过Ninject使用了依赖注入。

我的（简化）解决方案如下所示：

Project 1: Windows Service (Composition Root)
^
Project 2: Server Engine & Heavy Lifting (Ninject Module)
^
Project 3: Persistence / DAL (Ninject Module)
^ 
Project 4: Interfaces & Basic / Shared functionality (Interfaces)

经过一些重大的开发，事实证明，我将需要创建一个用于与Windows Service通信的新的“客户端”库项目。此客户端变成一个新的项目（Project 5），并取决于功能Project 3和Project 4。即：

Project 5: Client (Class Library)
^
Project 3: Persistence / DAL (Ninject Module)
^ 
Project 4: Interfaces & Basic / Shared functionality (Interfaces)

3眼前的问题：

我不想把连接对象图的责任放在客户端的使用者身上。使用者应该像使用其他任何库一样使用它。您不必担心库的内部结构使其正常工作。

客户端是一个类库，没有自己的入口点来考虑我的合成根并建立对象图。

即使我在客户端中确实有一个入口点，我的阅读也表明我不应该对DI框架具有库依赖性：“在这种情况下（创建可重用的库），通常应该使您的库在没有DI容器的情况下工作。您自己不应该依赖于这样的容器，因为这会将容器拖入”（从中找到.NET库的正确组成根）。从另一篇文章中摘录的另一段摘录是：“仅应用程序应具有成分根，而库和框架则不应。” （摘自 http://blog.ploeh.dk/2011/07/28/CompositionRoot/）。

这些问题源于我已经内置了很多功能Project 3并且Project 4必须在其中使用的事实Client，但是这两个项目已经依赖于Ninject，因此通过代理，客户端也依赖于Ninject。

我可以使用各种方法轻松解决此问题，但是我没有找到一个有效的解决方案，它们都让人感到“ hacky”，就像我在圆孔中塞了方钉（使用依赖的类库的最佳做法是什么？为内部操作注入？）。