Visual Studio：單一解決方案還是很多解決方案？

Question

現在這個遺留代碼是多個項目，每個項目都有自己的解決方案。每個項目都通過編譯後的dll引用另一個項目。要讓主項目運行，你必須按照正確的順序通過10個以上的個人構建。

我想解釋如何在單一解決方案下移動所有項目是解決所有這些問題的好主意。我怎樣才能向其他開發者解釋這是一個更好的主意？我不明白這不是一條更好的路，但是我還是錯了？

Answer 1

你是正確的，我會解釋給其他開發商的利益

對我來說，最簡單的說法是建築方面1周時間大於1個號樓解決方案的10倍快的多。單獨加載每個不同的解決方案是非常繁瑣和耗時的。 Visual Studio是關於讓你的生活更美好，加載10次不同的解決方案只會讓你的生活變得更糟。

而且把所有的項目在一個解決方案意味着你得到了很多功能，如智能感知，重構現場支持，查找所有引用等..有現場項目引用產生比通過的DLL去一個多更好的體驗。重構是一個在通過DLL時非常有用的特性。

如果他們擔心在根項目上迭代時不斷重建世界的成本，那麼最好的方法是創建一個只構建根項目的新構建配置。解決方案支持多種構建配置，它們之間的切換速度非常快（比解決方案之間的切換快得多）。

Answer 2

自己動手做一個本地副本，然後你可以告訴他們爲什麼它更好。

Answer 3

我主要同意@JaredPar，但是在創建一個大規模解決方案時需要考慮幾件事情。

1. 性能 - 是的建築可能是少了繁瑣的任務，但重建爲數衆多的改變很少浪費週期，正如賈裏德說你可以構建CONFIGS緩解這種「核心」項目。另外，Visual Studio往往成爲一個資源浪費問題，根據我的經驗，隨着解決方案的增長，問題會加劇。如果你的核心部件不經常改變，那麼一直加載它們的好處是什麼？

2. 重構 - 這是一把雙刃劍IMO。是的，當所有的代碼都被加載時，重命名，移動，替換等操作更容易。然而，由於它更容易，所以當從架構的角度來看，這是不正確的方法時，人們會添加對項目的引用並跨項目邊界移動事物。因爲VS使得它很容易做到，你必須提防的人盲目重構，打破建築的準則

P & P具有發表關於這一主題的一些指導：http://msdn.microsoft.com/en-us/library/bb668953.aspx

這是一個有點過時和專門討論TFS，但一些主要概念仍然值得考慮。