我想你应该首先问“为什么这些引用服务引用，而不是二进制引用？”。
这可能是一个很好的理由，例如，该服务将部署到单独的计算机上，以解决方案中的其他项目。另一个原因是由服务提供的功能并不适合运行进程内，并且会使应用程序过于复杂。
在你的情况下，问题是：
“对于三个服务消费者，才有可能对我来说，只需通过一个二进制引用服务内部利用的服务的能力参考？”
如果答案是肯定的，那么稍做重构就可以简单地删除WCF服务库代码和服务引用。然后，您只需拥有三个项目，这些项目在运行时将所需的功能托管在进程中。
这是可取的，有几个原因，但这里有两个：
- 在处理代码是数量级比外的进程代码（如WCF服务）更快。
- 进程内代码管理和部署简单得多。
但是，如果你需要该服务的能力，以保持包裹在一个WCF服务，那么你仍然可以简化您的解决方案显着的：
- 移动服务进自己的解决方案，并
- 摆脱所有服务参考，并使用
ChannelFactory<T>.CreateChannel()直接调用服务。
ChannelFactory的工作原理是允许您通过直接引用服务二进制文件来调用服务。这否定了对没有共享二进制相关性的服务引用的需求。
这种做法是可取的原因有很多，但这里有两个：
- 无需服务引用，大大简化你的代码。
- 当服务发生变化时，不需要更新任何内容;通过二进制引用可以获得更改，并且与使用进程中的程序集一样自然。
常常看到的WCF服务实例包括作为解决方案，其中在溶液中的其他项目消耗经由服务引用的服务内的项目。这在我看来并不是很好的设计。首先，一个服务应该是从来没有驻留在一个单一的解决方案与消费者，其次，消费者应该直接消费服务，没有使用服务引用，除非绝对必要。
我不熟悉不使用参考的过程，而您的 解决方案看起来很有趣。我会读到
请做。在您完全控制服务和消费者的情况下，服务参考没有位置。我知道这听起来是规定性的，但经验证明它很有用。
数据库模型库驻留在BaseLibrary，这些都是在服务项目
哪个项目的引用该组件所用的参考方式 ？如果服务使用它，那么您可以使用该服务将其从解决方案中移出。但客户也使用它？如果是这样，这是否意味着客户端和服务都访问相同的数据库？否则，为什么他们都使用相同的数据模型？
将服务移动到另一个解决方案不会否定 只有一个地方为项目间代码的这种优势吗？
我强烈反对为项目间代码提供一个地方总是将项目集中在一个解决方案中的好理由。然后，您可以结束彼此完全无关的项目（从业务，技术或能力角度）共享解决方案，以便他们可以从这种“优势”中受益。在我看来，更好的策略是将普通程序集移除到自己的解决方案中，然后将其发布到本地NuGet服务器。任何需要此程序集的项目都可以从NuGet中检索它。
我要补充一点，我将呼吁喜欢引用时BaseLibrary命名空间：using（ BaseNameSpace.WCFName.ServiceClient等） – MoustacheDangerous
如果您认为这可能会解决您的问题，那么可以从添加引用的位置为程序集内部添加服务引用。 – Biscuits
我不知道@Biscuits我会检查这是否会有所帮助，但我认为我的问题是我想获得一个项目从一个被引用的项目继承服务引用，我不认为这是一回事。 – MoustacheDangerous