我查看了相關的問題，而且他們中沒有人提供了我正在查找的信息。ASP.NET網站部署最佳實踐資源建議
目前，我工作的團隊針對錯誤修復/增強部署了單個.aspx（和.aspx.vb）文件。我試圖影響變化，因爲我確實認爲部署「整個編譯站點」不太容易出錯。由於這是一件事情已經發生的重大變化，我的建議已經遇到了很大的阻力。
由於我的google-fu最近沒有達到標準，我希望SO社區可以告訴我，我脫離了我的搖桿，並且移動單個文件沒有任何問題，或者指向我真的很好的資源，可以讓我做出更強大的情況。
編輯：
這已經全部偉大的信息，並加強我已經做的論據，任何人都可以爭論的另一面？
對我個人而言立即回滾是最重要的。在追蹤變化時，網站項目再次非常困難。
你可以找到一個很好的詳細比較here。我在這裏複製這篇文章。
1）部署。如果你需要就地部署，這個模型是完美的。但是，由於您以明文形式顯示您的邏輯，因此不推薦。所以，任何有權訪問物理服務器的人都可能會弄亂你的代碼，你永遠不會注意到這一點。你可以嘗試做預編譯的網站，但是你會得到很多dll和幾乎不可觸及的aspx文件。微軟認識到這一限制併發布了Web部署項目工具。
2）您需要跟蹤您在本地更改的內容以及上傳到生產服務器的內容。沒有版本控制。Visual Studio具有Web Copy工具，但該工具無法提供幫助。我不得不建立自己的工具，它可以跟蹤基於Visual Source Safe的變更。
3）當您按F5進行調試執行時，只需2分鐘即可編譯並執行整個項目。當然你可以附加調試器到現有的線程，但這不是一個明顯的解決方案。 4）如果你試圖在飛行中產生控制，你將會遇到第一個無法解決的限制。如何引用其他頁面和控件。頁面和控件編譯發生在每個目錄的基礎上。在最好的情況下，你將獲得每個目錄的彙編，最糟糕的情況是每個頁面或控件都將獲得它自己的程序集。如果您需要從控件或其他頁面引用另一個頁面，則需要使用@Reference指令顯式地將其導入。
所以對於，
customControl = this.LoadControl（ 「〜/控制/ CustomUserControl.ascx」）作爲CustomUserControl;
你需要，
但是，如果你想真正動態添加的東西，不能把所有適當@Reference指令是什麼？或者如果你正在創建服務器控制並且它沒有ascx文件，那麼你沒有@Reference的地方？由於每個控件都有自己的組件，因此幾乎不可能做反射。
重新出現在Visual Studio 2005 SP1中的Web應用程序項目。他們解決了上述所有問題。
1）部署。每個項目只有一個dll。您可以創建可重新分發的包和可重複的構建。您可以進行版本控制和構建腳本。
2）如果你在代碼後面做了代碼，你可以只上傳一個dll。如果您更改了aspx，則可以上傳aspx更改。
3）執行最多需要2-3秒。
4）整個項目在一個程序集中，這有助於引用任何頁面或控件。結論。對於任何一種嚴肅的工作，你應該使用Web應用程序項目。特別感謝Rick Strahl在ASP.NET 2.0中的精彩文章Compilation and Deployment。
這對回滾很不利。如果你作爲一個網站或網絡應用部署，是的，你可以做一個或兩個文件的快速補丁，但如果你需要回滾到以前的版本呢？祝你好運追蹤所有更新的文件，以使新版本。由於組織原因，我更喜歡「版本」的概念，編譯好的網絡應用比「網站」項目更加內聯。
偉大的一點... – andrewWinn
我們遇到了這個困境，最終以編譯版本爲主，出於安全原因。如果你的站點是外部的，你可以通過允許vb文件以純文本的形式存在，從而危及你的安全。我意識到，如果他們真的想要的話，仍然可以獲得你的代碼，但它會是一個額外的障礙，他們需要經歷。如果您使用Visual Studio作爲開發環境，則可以發佈預編譯的網站，並在發佈時檢查命名的程序集選項，這實際上會爲每個aspx頁面創建一個dll，以便您可以根據需要進行一次性更改。這是我們發現的一個很棒的功能，因爲我們不斷更新整個網站，有時候會更新不應該更新的內容。使用該功能後，我們不再有更新推送，不應該。至於回滾，我希望你使用某種類型的源代碼控制/版本控制系統。 Team Foundation Server非常適合版本控制/源代碼控制，但價格相當昂貴。
部署單個文件以進行錯誤修復和部署並不是明智的策略。這聽起來像你需要一個全面的構建和部署過程。這並不意味着它必須變得複雜，因爲現在有一些好的工具。
構建和部署可以得到詳細的信息，因此最低限度嘗試查看Microsoft Web Deployment Tool（http://www.iis.net/extensions/WebDeploymentTool）。在構建服務器上安裝該工具並將其安裝在部署服務器上。使用Visual Studio Publish命令在本地分級您的ASP.NET內容，然後使用上述工具同步部署服務器上的整個軟件包。我喜歡這種方法，因爲它可以完全自動化。在進行構建和部署時，要實現完全自動化以減少潛在的錯誤。
這是最低要求，但您至少要確定在特定文件發生更改時，它們在部署服務器上全部同步。
什麼是最好的部署策略取決於你在什麼樣的環境中工作，以及你正在使用什麼樣的開發者。
與平面佈局開始朝編程工作的視覺藝術家都在調整個人頁面的生成和釋放等等。另外.aspx.vb文件僅僅是服務器端腳本，而不是真正的編程。
程序員通常開始在命令行和分支出來的環境，如網絡和理解的感覺良好的編程習慣應適用過的網頁，包括標準測試和發佈週期（和編譯代碼）。
如果該網站是在不斷變化的各個頁面會更有意義，但如果您需要提供安裝包到生產組的MSI文件是要走的路，因爲他們可以在需要時方便地備份出來。
如果您評價一下您的團體需求，包括人人小組中的豐富的經驗，你應該能夠說服用戶可以自己或組。這不是一個更好的問題，但它提供了最好的商業模式。
我同意Rich。
更多信息：
部署你的源代碼阿拉的.vb文件到服務器是一個壞主意。編譯它。如果可以混淆，只是不要部署直接來源。想象一下攻擊者可以訪問系統。他們可以很容易地改變你的代碼，你可能沒有注意到。是的，您可以使用反射器等工具進行反編譯。但是，真正難以反編譯完整站點，進行所需的更改並將其重新投入生產。
部署一個單獨的文件很可能會導致一些類型的問題相關的模塊中。我猜你們真的沒有做QA。告訴他們是時候長大了。
編譯你的網站會減少JIT（準時）編譯。考慮表現。
我也要去猜測，幾乎每個人都擁有生產服務器的訪問。從公司的角度來看，這是不好的，因爲你沒有控制權。當員工在離開前決定造成一些破壞時會發生什麼？
你所描述的是牛仔編碼內聯。當然，乘坐營救很有意思，但這種風格經常吹噓一切。
Rick Strahl文章：http://www.west-wind.com/presentations/AspNetCompilation/AspNetCompilation.asp – Nick
Web應用程序項目沒有首先出現在VS 2005 SP1中。他們是VS 2003的主要開發模式。在MS推出網站模型之後，開發人員社區出現了這樣一個負面反應，他們必須做出迴應，並將其重新引入到VS 2005的SP中： http://www.codersbarn.com/post/2008/06/01/ASPNET-Web-Site-versus-Web-Application-Project.aspx – IrishChieftain
@IrishChieftain：+1並編輯我的答案。 – Mahin