我上了不少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和其他文件。