我有一個大型解決方案，其中包含大約320個項目，即使對單個Web窗體進行細微更改也會導致構建時間過長，以便測試/調試一個小的更改。我懷疑爲了「觸摸」文件日期時間和導致多重重建後構建文件複製任務。在Visual Studio中重建C＃項目的原因
除了比二進制輸出文件更新的源文件之外，在沒有任何強烈的命名和版本影響的情況下，VS 2010是否有任何其他原因運行重建而不是源文件？
附錄：我沒有直接影響源樹的大小或形狀。它是一個穩定的核心產品的主幹，任何短期的「非業務」變化被認爲是有風險和/或成本高昂的。我將提出我在這裏收到的答案中提到的要點，作爲項目未來方向的輸入。
C＃重建是因爲文件已被更改，或者依賴項已被更改，但也經常出現「無明顯原因」。您通常可以連續創建2到3次而無需進行任何更改，並且C＃將逐漸停止並重建大量代碼。
打開工具>選項>項目和解決方案>構建和運行>僅在運行時構建啓動項目和依賴關係。這將使構建最小化爲只打算執行的項目的依賴關係，因此除非一切都是一個大規模的依賴關係樹，否則這將顯着減少構建中考慮的項目數量。
但是，更好的解決方案是避免要求它首先編譯。
每個項目都會增加構建的額外開銷。在我的電腦上，這是大約3秒。通過將兩個項目的代碼合併爲一個.csproj文件，我可以節省3秒的編譯時間。因此，對於300多個項目，您可以通過合併項目來縮短構建時間10分鐘 - 即儘可能在一個程序集中使用許多模塊/名稱空間，而不是使用多個程序集。你會發現你的應用程序啓動時間也得到了改善。
許多項目不需要一直建設。將這些作爲庫項目分開，並鏈接到（參考）二進制文件
也禁用「複製本地」，而是指向所有輸出路徑到共享文件夾 - 這將顯着減少開銷，避免320 320副本遍佈你的硬盤。
添加僅構建實際工作的程序集的新構建配置（例如「Debug FastBuild」）。通過配置管理器，您可以取消不想構建的項目，並且它們會被構建系統忽略。當您從源頭控制獲取代碼，構建一個完整的「調試」打造刷新一切，然後再切換回「的FastBuild」
謝謝你的基本技巧，我知道當構建大型解決方案時，小小湊合可以非常有用。 – Pimenta 2012-10-18 13:03:20
320項目是依賴關係樹中的很多文件：所有需要檢查構建引擎的更改。使用諸如Process Monitor之類的東西可以讓你看到正在進行什麼文件操作來確認這一點。在運行時加載的320個程序集（在.NET框架程序集的頂部）也會減慢你的應用程序的運行速度，並且真的會減慢調試器（很多符號的加載速度）。看看Debug | Windows |模塊來查看加載的模塊）。
除了減少解決方案中的項目數量（很可能有多個解決方案，每個解決方案都包含一個項目子集），您是否真的需要這麼多獨立的項目？在調試器之外，.NET加載器只會根據需要加載並從程序集中加載代碼，較大的程序集並不意味着加載時間較慢並避免Windows加載程序的每個程序集開銷。
我相信他們可以幫助最後一點與後構建ILMere步驟 – 2013-03-19 18:16:29
你可以嘗試建立使用的MSBuild和/ V解決方案：d（爲診斷日誌）。
日誌中可能會提示爲什麼項目不是最新的。
首先，檢查以確保對其他項目的引用是PROJECT引用而不是程序集引用。
其次，檢查循環引用。
第三，將日誌詳細程度設置爲DIAGNOSTIC並查看第一行，並瞭解爲什麼在第一次構建解決方案後重建項目。
還有很多東西可以檢查，但先看看這3件事。
我認爲在很久以前你已經超過了Visual Studio設計的舒適的320項目的限制。
這裏有很多很好的建議，但如果你真的必須保留320個項目，你可能想要用Visual Studio來構建和設計自己的構建過程。
就像我在我的評論中所說的，至少在Windows中，我建議使用的構建工具是psake，它建立在PowerShell上（因此包含在每個現代Windows機器上），功能非常強大，足夠輕量級提交整個東西給你的源代碼管理。
我不知道如何解決您的重建問題，但解決方案中的320個項目不是一個好主意。如果我是你，我會發佈一個問題，詳細說明這些項目的類別，它們之間的一般依賴關係，尋求讓它們易於管理的最佳方法。 – 2011-03-25 07:47:14
我的上帝，320個項目？我打了10次，這是無法忍受的。我很抱歉。爲了解決這個問題，您可以使用像[psake]（https://github.com/psake/psake）這樣的工具來創建多個解決方案或手動構建流程，這些工具可以將特定場景的基本項目配對。 – 2013-03-19 18:14:40