我上了不少DotNetNuke的網站工作，偶爾（我還沒有想出的共同因素尚未），出版後，當我使用數據庫發佈嚮導從微軟創建腳本對於我在Dev服務器上創建的站點，在主機上運行腳本（通常爲GoDaddy.com）並上傳站點文件後，出現錯誤...我99.9％確定它與文件無關，所以不知道DB從哪裏開始。不幸的是，DotNetNuke沒有得到YSOD，而是一個通用的錯誤，沒有真正的方法來找到發生的實際異常。問題與DB通過數據庫發佈嚮導從MSFT
我只是好奇，如果任何人使用數據庫發佈嚮導也有類似的部署問題，如果是這樣，他們是如何克服呢？我擁有RedGate工具集，但一些像GoDaddy這樣的主機不允許你直接連接到他們的服務器......
數據庫發佈嚮導的生成腳本通常需要調整，因爲它有時會得到錯誤的表/在處理約束時創建程序。我所做的是首先備份數據庫，然後運行腳本，如果出現錯誤，我將該查詢移至腳本末尾。繼續恢復數據庫並運行腳本，直到它工作。
您應該能夠通過設置來露出下面的錯誤消息，在web.config如下：
customErrors mode="Off"
你能否詳細說明「並上傳網站文件」？ DNN的新實例？更新現有網站？升級DNN版本？如果升級或更新 - 要添加/覆蓋哪些文件？
此外，使用GoDaddy的時候，你能檢查驗證（根據您的IIS版本的網絡服務或asp.net機器帳戶）網站的身份具有足夠的權限，以網站的文件系統？它應該具有修改權限，如果您覆蓋文件，則可能需要重新應用這些權限。
測試你的一個新的本地數據庫上生成的腳本（使用免費的SQL Express產品或全餐服務）。如果它在當地運行良好，那麼你可以確信它會在其他地方運行，所有事情都是平等的。
如果在本地運行，使用排除過程和工作的方式通過腳本執行查找問題的代碼是炸彈。
我的預感是腳本的順序可能會關閉。我認爲我以前用數據庫發佈嚮導發生過這種情況。
只是閱讀你的後續行動。在任何情況下，我遇到了問題，它總是與web.config中的連接字符串有關。即使經過數小時的盯着它，它始終是web.config中的連接字符串問題。起來，散散步，然後回來。
如果您收到DNN的錯誤頁面之一，有可能已經記錄錯誤的事件日誌表的機會。
有跡象表明，我想看看兩個領域 -
取決於到底發生了什麼，什麼DNN是顯示您可能能夠手動查看事件日誌表內，拔出存儲在那裏的XML數據，並對其進行分析找到有關特定錯誤的堆棧跟蹤和詳細信息。
但是我發現儘管我使用備份和恢復數據庫的部署方式獲得了更好的整體體驗，那樣我就可以100％確定所有對象都能正確移動，並且實際上它在我的經驗中效果更好。
隨着GoDaddy我知道另一個主要的常見問題是不正確的文件權限，防止DNN修改它需要做的web.config和其他文件。