我遇到很多與發佈有關的問題，例如當您需要對代碼進行小的更改時，有時生成的DLL文件（dll文件，例如default.aspx.CS發佈時）無法被IIS識別，說明代碼隱藏是錯誤的或一些東西。對不起，不記得確切的錯誤信息。我希望你知道我的意思。ASP.NET網站發佈與複製？
因此，我通常會做一個簡單的Copy Paste而不是發佈操作。
你能告訴我什麼，我錯過了不使用發佈方法？發佈如何更好？或者你更喜歡哪一個，爲什麼？
基本上它是一個利弊的情況。
三江源
嗯，這取決於你的意思是「拷貝」的內容：
隨着Publishing你有選擇，pre-compile全部或者應用程序的一部分。您可以將publish複製到文件系統中的本地文件夾（而不是目標/主機），然後複製更新的文件（僅限於）。如果您正在編寫「代碼隱藏」（c＃/ vb代碼）更改，這意味着您可能只需「複製」/覆蓋dlls。不用說，如果你已經做了「內容」改變（html/razor/script/etc）的改變，那麼你需要複製/覆蓋這些改變。
如果您是新手部署，您可能會發現自己只需複製/覆蓋「所有」，這是最安全的方法，即。一旦你獲得了更多的經驗，你將「認識到」你只需要更新哪些資產（一個或幾個dlls或內容代碼，而不是「所有」）。這沒有什麼神奇之處，通常，只需在您的Web應用程序published（本地）或rebuild之後查看dll /文件的時間戳即可。
我建議你做一個local publish，這樣你就可以看到服務器上真正需要的東西。發佈到本地文件系統/文件夾的文件是主機/服務器上需要的文件。這樣做將可視化和消除任何「神祕」有到Publishing：
所以「拷貝」可能意味着以上，或者如果你的意思是你會簡單地複製所有的開發代碼（生(vb/cs)html/cs/vb）到你的主機，那麼這意味着你的網站將dynamically compiled因爲需要每個資源/要求（沒有什麼是pre-compiled）。也是「容易」，但你確實會丟失pre-compilation，這意味着當你的每個網頁被請求/需要時（ASP.net需要動態編譯）會有延遲。另外，您還將在服務器上顯示您的源代碼。根據你的情況，這可能沒有多大意義，但還有一件事需要考慮。
你的答案是一個非常詳細的答案，它告訴我你清楚地瞭解了部署過程。但是，我想澄清一件事：我認爲很高興知道哪些文件實際需要更新;然而，當我的團隊更新網站時，我會更新整個網站，而不僅僅是替換一些DLL ......這種方式很有效，但容易出現人爲錯誤。我寧願將整個測試過的應用程序上傳到IIS，將其解壓縮，然後將IIS指向新文件夾。你怎麼想？ –
@HoàngLong恕我直言，就像「ftp所有」一樣。 Ftp一切都不太容易出現其他問題 - 例如應用程序在這些新文件夾上的權限，Web場/複製問題等。另外，如果您有直接/裸機訪問服務器的權限，那麼這種方法似乎是唯一可行的。另一種方法是'WebDeploy'，它以一種「智能的方式」爲你做事（指出你的變化）。如果它可以提供給你，這是值得研究的東西。 – EdSF
是的，它幾乎就像「ftp所有」（除了它不會有冗餘文件，因爲整個web應用程序文件夾被替換）。 WebDeploy似乎是一個有趣的選擇，雖然...我會玩它 –
假設我們考慮的一個aspx頁面和隱藏文件的aspx.cs代碼中，有部署你的網站的三種方式：
這三種模式都有各自的優缺點。
第一個是增量更新最容易，但同時也是最容易發生不必要的修改。
其次也很容易，可以從VS調用，它將關閉在服務器上的一些不需要修改的可能性，但.aspxses還需要時間在第一次請求
三所花費的時間和一些手動操作來編譯但是可以防止任何變化，並且還可以加速網站的熱身，因爲資源編輯不是必需的。這對共享環境非常有用。
非常感謝。 –
發佈也受您選擇部署的應用程序的類型影響; Web站點應用程序允許您只發布幾個文件，而Web應用程序通常需要將ASPX和適當的DLL部署到正確的文件夾。閱讀http://stackoverflow.com/questions/398037/asp-net-web-site-or-web-application獲取更多信息。 – dash
感謝您的評論。但這並不能完全幫助我。例如，是否有任何性能差異？也許，它可以被概括爲「Do Web Application，而不是發佈網站」 –