作爲我們構建過程改進的一部分，我們目前正在討論是否應該在本地開發環境中將CI項目生產環境中的項目/解決方案文件分開。針對本地和構建環境的不同解決方案/項目文件
之所以出現這個問題，是因爲我們之前項目中遇到的參考問題。頻繁地，人們會錯誤地在錯誤的位置添加對組件的引用，這將意味着它可以在當地環境中正常工作，但可能在別人或構建機器上破壞。
此外，參考路徑位於csproj.user文件中，這意味着這些文件必須提交到源代碼控制，因此每個人都必須共享這些相同的設置。
因此，我們正在考慮在CI服務器上分別開發項目和解決方案，以便在構建時使用這些項目而不是本地開發項目。
它有明顯的缺點，例如維護這些單獨的文件和需要定義和遵循的關聯進程的開銷，但它的好處是我們將更多地控制確切的發生生產環境。
我無法找到的是關於這個問題的任何事情 - 不能相信我們是唯一想到這個問題的人 - 所有的想法都是受歡迎的。
通常情況下，您將以某種形式或另一種形式爲您的Production創建項目/腳本，因此將另一個Solution文件放在一起不會出現在圖片中。
培養每個人使用項目引用，並在外部程序集引用的項目文件結構下創建一個目錄會更容易。這樣每個人都遵循相同的環境。
我強烈建議不要這樣做。
引用路徑不僅存儲在.user文件中。提示路徑存儲在項目文件本身中。您不應該將.user文件檢入到源代碼管理中。
讓所有開發人員使用一套（好的，可能是版本化的）解決方案/項目文件，並且其發佈配置是您最終在生產中構建的。分開的項目文件會導致混亂，當某些項目設置被調整，沒有被執行，並且投入生產。
您可能還檢查了這一點：
http://www.objectsharp.com/cs/blogs/barry/archive/2004/10/29/988.aspx http://bytes.com/forum/thread268546.html
我們已經改變了我們的項目結構（利用SVN的外部組件），其中每個項目現在是完全獨立的。也就是說，任何引用都不會與項目目錄一致（例如，如果項目A引用了ASM X，則ASM X存在於ProjectA的子文件夾中）
我懷疑這應該有助於解決某些問題問題，但我仍然可以看到對構建項目擁有更多控制權的一些優勢。
在我們最大的項目（包括許多應用程序的系統），我們有以下結構
/3rdPartyAssemblies
/應用1
/應用2
/App3的
/.....
所有外部程序集都添加到3rdPartyAssemblies/Vendor/Version/...
我們有一個CoreBuild.sln文件，它充當所有程序集的MSBuild腳本這是共享，以確保建立依賴性順序（即，確保App1.Interfaces在App2之前構建，因爲App2具有對App1.Interfaces的引用）。
所有的應用程序間引用都指向/ bin文件夾（我們不使用bin/debug和bin/release，只是bin，這樣引用保持不變，我們只是根據構建目標更改發佈配置）。
Cruise Control在構建任何其他應用程序之前構建任何依賴項的核心解決方案，並且由於服務器上存在3rdPartAssemblies文件夾，因此我們確保開發人員機器和構建服務器具有相同的開發佈局。
@David - 不管你信不信這就是我們剛纔的實際情況，但它仍然會給我們帶來麻煩！
雖然我們正在做一些修改，但由於移動到TeamCity和多個構建代理，我們不得不進行一些更改 - 因此我們無法引用與當前項目不同的目錄，正如我在之前的回答中所述。
看看這個鏈接的外部材料部分，明白我的意思 - http://www.dummzeuch.de/delphi/subversion/english.html
我知道這是不合時宜的。但是，我發現處理引用問題的最佳方式是將文件夾映射到驅動器盤符（如R），然後所有項目都將內容複製或複製到該文件夾中。然後，所有引用都是R：\ SomeFile.dll等。這會讓您瞭解有時引用是通過絕對路徑添加的問題，有時會相對添加它們。 （這與我不記得的「HintPath」有關）
那麼好的是，你仍然可以在你的構建服務器上使用相同的解決方案文件。說實話是絕對必須的，因爲你失去了在開發機器上構建的內容與在構建服務器上相同的確定性。