Visual Studio項目應該包含在多個解決方案中嗎？

注意：這是適用於C++，C++/CLI和C＃的商店，其中一些產品以三種產品的組合形式交付。Visual Studio項目應該包含在多個解決方案中嗎？

我們目前有一個規則，即項目應該只有一個包含解決方案。該規則最初是由於Visual Studio的源代碼管理插件無法處理多個解決方案中包含的項目而導致的，因此當從一個解決方案更改爲另一個解決方案時，總是嘗試更改源控制綁定。

由於其他原因，我們將完全停止使用源代碼管理插件（而不是放棄源代碼管理，只是大腦死亡插件）。它重新提出了是否繼續限制項目的政策只能包含在一個解決方案中的問題。

我們在多個可交付產品所使用的庫，dll和程序集中有相當多的代碼，而且我們目前使用一個解決方案間依賴性管理系統來控制此問題，因此如果有人正在解決方案中工作最終產品，請求構建依賴性解決方案是一件簡單的事情，該解決方案會啓動Visual Studio的其他實例來構建它們。該系統的工作原理，但有以下缺點：

爲共同的項目解決方案通常太胖，包含由產品所需的幾個項目目前正在開發和平時多了很多不需要的了開發工作在手邊。他們僅僅被納入一種涵蓋所有鬆散相關項目的全面解決方案。由於編譯了不需要的代碼，這會導致編譯時間延長。
在我們試圖解決上述胖解決方案的過程中，我們經常會留下一個太瘦的解決方案，其中只包含一個項目。其中每一項都需要在解決方案間依賴性管理系統中進行額外配置。這也可以在Visual Studio的多個實例被啓動時增加構建時間。

我在考慮修改政策，允許多個可交付產品中使用的項目包含在多個解決方案中。我們可以消除解決方案間依賴關係管理，並大大減少解決方案的數量（每個產品最多可減少一個）。我擔心這次重組的工作量以及是否值得付出努力。恐怕在團隊一直工作之前，我甚至無法發現潛在的益處。我還預見了一些潛在的問題，這是真正的問題。

在單一解決方案中執行大量項目會在Visual Studio 2005（我們當前的開發平臺）中出現任何穩定性問題嗎？它在VS 2008或VS 2010中有更好的表現嗎？
如果項目包含在多個解決方案中，如果項目配置被修改（如添加新配置），如何管理對多個解決方案的影響？

對於任何的環境已經工作與每個可交付的產品一個解決方案，具有共同的構成零件包含在多個項目的解決方案：你有沒有遇到任何顯著缺點，這樣的配置？

來源

2009-11-01 GBegen

不，請使用盡可能多的解決方案。

例如，我們有一個大型解決方案，可以構建大約53個項目。它包含一個安裝程序和卸載程序，以便它們可以方便地由我們的構建服務器構建，但如果我想要處理這些應用程序，我將它們加載到它們自己的解決方案中（每個項目有一個項目），而不是一直裝載其他69個項目不必要的項目他們對其他項目沒有任何依賴性，所以這樣做沒有任何問題（實際上，解決方案的加載和構建方式更快，效率更高）

多種解決方案唯一的解決方案是在任何情況下，如果你沒有建立依賴關係，你必須小心謹慎（例如，如果你不建立一個庫，那麼你需要小心，當它的源代碼發生變化時它就會被建立，因爲它不會再爲你自動建立）

編輯

要回答你的問題的最後一部分（因爲有需要的問題路程，而找你e編輯答案！），VS2005中解決方案唯一的問題是它的速度很慢，其中包含很多項目。 VS2008是很多在加載大型解決方案時速度更快，但主要目的只是解決方案中的項目越多，構建所需的時間越長（即使它只是跳過不需要構建的項目，需要很長時間）

如果您添加一個新的解決方案配置，那麼只需製作一個超級解決方案（或保留現有的解決方案！），然後對其進行修改，以便將其應用於所有項目一氣呵成。您仍然必須將該新配置添加到您要使用的任何單獨解決方案中，但是如果它們是單項目解決方案，則可以將其刪除，然後加載.csproj，並且會自動重建所有配置中的配置它。並且增加新的配置可能不會經常發生。

來源

2009-11-01 19:43:13

我也在一個環境中工作，這個環境有很多常用項目在幾個可交付成果中使用。我們的政策是每個可交付應用的一個解決方案。所以一個共同的項目可能包含在幾個解決方案中。這對我們非常有效。常見的項目雖然包含在單獨的解決方案中，但都映射到相同的源代碼存儲庫位置。因此，如果通用代碼發生更改，所有包含的應用程序都會受到影響（我們的持續集成系統）可用作檢查其他應用程序是否因通用代碼更改而中斷。

您在VS解決方案中擁有的項目越多，加載所需的時間就越長，並且聽起來很複雜，因此無法在單個解決方案中管理不同的構建配置和依賴項。

來源

2009-11-01 19:49:48

用具有幾種解決方案，一個項目的主要問題是：