我在相当多的DotNetNuke网站上工作，偶尔(当我尚未弄清共同因素时)，当我运行Microsoft的数据库发布向导为在Dev服务器上创建的网站创建脚本时主机上的脚本(通常是GoDaddy.com)，然后上传站点文件，我得到一个错误...我99.9％的确定它与文件无关，所以不确定在数据库中从哪里开始。不幸的是，使用DotNetNuke并没有得到YSOD，而是一个通用错误，没有真正的方法来查找已发生的实际异常。

我只是好奇是否有人使用数据库发布向导遇到了类似的部署问题，如果是的话，他们如何克服了这些问题？我拥有RedGate工具集，但是像GoDaddy这样的某些主机不允许我们直接连接到他们的服务器...

解决方案

回答

通常需要对数据库发布向导的生成脚本进行调整，因为在处理约束时，有时会导致表/过程创建的顺序错误。我要做的是先备份数据库，然后运行脚本，如果遇到错误，则将该查询移至脚本末尾。继续还原数据库并运行脚本，直到它起作用为止。

回答

通过在web.config中设置以下内容，我们应该能够公开潜在的错误消息：

customErrors mode="Off"

我们能否详细说明"并上传站点文件"？ DNN的新实例？更新现有网站？升级DNN版本？如果要升级或者更新-我们要添加/覆盖哪些文件？

另外，在使用GoDaddy时，是否可以检查以确认网站的身份(网络服务或者asp.net计算机帐户，取决于IIS版本)对网站的文件系统具有足够的权限？它应该具有修改权限，如果要覆盖文件，则可能需要重新应用这些权限。

• IIS6(XP，Server 2000，2003)= ASP.Net计算机帐户
• IIS7(Vista，Server 2008)=网络服务

回答

在新的本地数据库上测试我们生成的脚本(使用免费的SQL Express产品或者全餐交易)。如果它在本地运行良好，那么我们可以确信它会在其他所有条件相同的情况下在其他地方运行。

如果在本地运行时炸弹爆炸，请使用消除过程并逐步执行脚本以查找有问题的代码。

我的直觉是脚本的顺序可能会关闭。我想我曾经在数据库发布向导中发生过这种情况。

回答

只需阅读跟进内容即可。在遇到问题的每种情况下，它总是与web.config中的连接字符串有关。即使经过数小时的观察，它仍然始终是web.config中的连接字符串问题。起床，散散步，然后再回来。

回答

如果我们正在获取DNN的错误页面之一，则可能它已将错误记录到事件日志表中。

回答

我要看两个领域-

• 我们是否在dbo模式中运行，并且脚本数据库是否在使用dbo？
• 我们是在开发环境中还是在生产环境中使用对象限定符？ (查看sqldataprovider配置设置)

回答

根据实际发生的情况以及DNN向我们显示的内容，我们也许可以手动查看EventLog表，取出其中存储的XML数据，然后解析它以查找堆栈跟踪以及有关特定错误的详细信息。

但是，我发现尽管使用数据库的备份和还原在部署方面获得了更好的整体体验，但是我100％确信所有对象都正确移动，并且根据我的经验，它可以更好地工作。

使用GoDaddy，我知道另一个主要的常见问题是文件权限不正确，从而阻止DNN修改web.config和它需要执行的其他文件。