我在相当多的DotNetNuke网站上工作，偶尔（我还没有找出常见因素），当我使用Microsoft的数据库发布向导为我在Dev服务器上创建的网站创建脚本时，在主机（通常是GoDaddy.com）上运行脚本并上传站点文件后，我收到错误...我99.9％确定它与文件无关，所以不确定从DB开始的位置。不幸的是，使用DotNetNuke，你没有得到YSOD，而是一般错误，没有真正的方法来找到发生的实际异常。
我只是好奇是否有人使用数据库发布向导有类似的部署问题，如果有，他们如何克服它们？我拥有RedGate工具集，但像GoDaddy这样的主机不允许你直接连接到他们的服务器......
答案 0 :(得分：1)
数据库发布向导生成的脚本通常需要进行调整，因为在处理约束时，它有时会导致表/过程创建的顺序错误。我所做的是首先备份数据库，然后运行脚本，如果我收到错误，我将该查询移动到脚本的末尾。继续还原数据库并运行脚本，直到它运行。
答案 1 :(得分：1)
我会看两个方面 -
答案 2 :(得分：0)
您应该能够通过在web.config中设置以下内容来公开基础错误消息：
customErrors mode="Off"
您能详细说明“并上传网站文件”吗？ DNN的新实例？更新现有网站？升级DNN版本？如果升级或更新 - 您要添加/覆盖哪些文件？
此外，使用GoDaddy时，您是否可以检查以验证网站的身份（网络服务或asp.net计算机帐户，具体取决于您的IIS版本）是否具有对网站文件系统的足够权限？它应该具有修改权限，如果要覆盖文件，可能需要重新应用这些权限。
答案 3 :(得分：0)
在新的本地数据库上测试生成的脚本（使用免费的SQL Express产品或全餐交易）。如果它在本地运行良好，那么你可以确信它会在其他地方运行，一切都是平等的。
如果在本地运行它时会发生爆炸，请使用淘汰过程并按照脚本执行的方式查找有问题的代码。
我的预感是脚本的顺序可能会关闭。我想我以前在数据库发布向导中已经发生了这种情况。
答案 4 :(得分：0)
请阅读您的跟进。在我遇到问题的每一种情况下，总是与web.config中的连接字符串有关。即使经过几个小时的盯着它，它仍然是web.config中的连接字符串问题。起床，散步，然后回来。
答案 5 :(得分：0)
如果您收到DNN的错误页面之一，则可能会将错误记录到事件日志表中。
答案 6 :(得分：0)
根据发生的具体情况和DNN显示的内容，您可以手动查看EventLog表，提取存储在那里的XML数据，并解析它以查找堆栈跟踪和有关特定错误的详细信息在手边。
然而，我发现虽然我使用数据库的备份和恢复进行部署可以获得更好的整体体验，但这样我100％确定所有对象都能正确移动，老实说，根据我的经验，它可以更好地工作。GoDaddy我知道另一个主要的常见问题是文件权限不正确，导致DNN无法修改web.config及其需要执行的其他文件。