我想你應該首先問「爲什麼這些引用服務引用，而不是二進制引用？」。
這可能是一個很好的理由，例如，該服務將部署到單獨的計算機上，以解決方案中的其他項目。另一個原因是由服務提供的功能並不適合運行進程內，並且會使應用程序過於複雜。
在你的情況下，問題是：
「對於三個服務消費者，纔有可能對我來說，只需通過一個二進制引用服務內部利用的服務的能力參考？」
如果答案是肯定的，那麼稍做重構就可以簡單地刪除WCF服務庫代碼和服務引用。然後，您只需擁有三個項目，這些項目在運行時將所需的功能託管在進程中。
這是可取的，有幾個原因，但這裏有兩個：
- 在處理代碼是數量級比外的進程代碼（如WCF服務）更快。
- 進程內代碼管理和部署簡單得多。
但是，如果你需要該服務的能力，以保持包裹在一個WCF服務，那麼你仍然可以簡化您的解決方案顯着的：
- 移動服務進自己的解決方案，並
- 擺脫所有服務參考，並使用
ChannelFactory<T>.CreateChannel()直接調用服務。
ChannelFactory的工作原理是允許您通過直接引用服務二進制文件來調用服務。這否定了對沒有共享二進制相關性的服務引用的需求。
這種做法是可取的原因有很多，但這裏有兩個：
- 無需服務引用，大大簡化你的代碼。
- 當服務發生變化時，不需要更新任何內容;通過二進制引用可以獲得更改，並且與使用進程中的程序集一樣自然。
常常看到的WCF服務實例包括作爲解決方案，其中在溶液中的其他項目消耗經由服務引用的服務內的項目。這在我看來並不是很好的設計。首先，一個服務應該是從來沒有駐留在一個單一的解決方案與消費者，其次，消費者應該直接消費服務，沒有使用服務引用，除非絕對必要。
我不熟悉不使用參考的過程，而您的 解決方案看起來很有趣。我會讀到
請做。在您完全控制服務和消費者的情況下，服務參考沒有位置。我知道這聽起來是規定性的，但經驗證明它很有用。
數據庫模型庫駐留在BaseLibrary，這些都是在服務項目
哪個項目的引用該組件所用的參考方式 ？如果服務使用它，那麼您可以使用該服務將其從解決方案中移出。但客戶也使用它？如果是這樣，這是否意味着客戶端和服務都訪問相同的數據庫？否則，爲什麼他們都使用相同的數據模型？
將服務移動到另一個解決方案不會否定 只有一個地方爲項目間代碼的這種優勢嗎？
我強烈反對爲項目間代碼提供一個地方總是將項目集中在一個解決方案中的好理由。然後，您可以結束彼此完全無關的項目（從業務，技術或能力角度）共享解決方案，以便他們可以從這種「優勢」中受益。在我看來，更好的策略是將普通程序集移除到自己的解決方案中，然後將其發佈到本地NuGet服務器。任何需要此程序集的項目都可以從NuGet中檢索它。
我要補充一點，我將呼籲喜歡引用時BaseLibrary命名空間：using（ BaseNameSpace.WCFName.ServiceClient等） – MoustacheDangerous
如果您認爲這可能會解決您的問題，那麼可以從添加引用的位置爲程序集內部添加服務引用。 – Biscuits
我不知道@Biscuits我會檢查這是否會有所幫助，但我認爲我的問題是我想獲得一個項目從一個被引用的項目繼承服務引用，我不認爲這是一回事。 – MoustacheDangerous