通常情况下，你会在正确的位置，但我们最近推出了一个全新的社区网站…为了社区，靠社区。
耶……带我去社区!
社区博客是社区成员的个人观点，绝不是DNN公司或DNN平台的官方立场。这是一个表达个人对DNNPlatform、社区及其生态系统的想法的地方。你有有用的信息，你想分享与DNN社区的特色文章或博客?如有，请联系(电子邮件保护)．
社区博客的使用由我们的社区博客指南-请在评论或张贴前阅读。
我很高兴地宣布，扩展验证服务(EVS)已正式完成测试，EVS v1.0现已上线。如果你还没有经历过EVS，我建议你看看我的第一篇博客文章(/社区博客/ cid / 147439 / Extension-Verification-Service-EVS.aspx)．如果你试用了EVS测试版并提交了反馈，非常感谢你的帮助。关于这个最新版本的任何其他问题或评论都可以发布到EVS论坛http://bit.ly/evsfeedback．
这个版本中EVS最重要的变化集中在SQL Azure兼容性扫描程序上。在最初的版本中，EVS使用SQL Azure Migration Wizard扫描扩展中发现的所有SQL脚本。这种方法存在两个问题:
有一些SQL Azure兼容性问题，迁移向导仅通过扫描脚本文件无法识别。例如，要检测丢失的聚集索引，迁移向导只能在处理实际的SQL数据库时检测这些索引。
扩展开发人员更新旧的遗留脚本文件来支持SQL Azure是不现实的，因为对升级脚本的更改可能会对处于升级路径中间的用户产生意想不到的后果。为了解决这个问题，我们显然需要添加对安装脚本的支持。
由于上面列出的限制和一些额外的特性要求，EVS的整个SQL扫描程序部分重新构建，现在包括以下函数。
支持打包安装脚本。
检测和警告对核心数据库对象所做的修改。
对{databaseOwner}和{objectQualifier}令牌使用不当/不完整的检测和警告。
对SQL脚本文件中发现的任何SQL Azure兼容性问题进行检测和警告。
SQL Server中DNN主要版本的脚本执行检测和警告。
检测和警告在SQL Server中发现的任何SQL Azure兼容性问题。
SQL Azure中DNN的主要版本上的脚本执行检测和警告。
检测和警告SQL Azure数据库备份和恢复过程中可能出现的任何问题。
执行SQL Azure兼容性问题扫描时使用以下工作流程:
确定清单是否指定了任何SQL脚本。
在SQL脚本列表中检查“Install”脚本。
如果有一个“安装”脚本，那么只向前移动该脚本和任何后续版本脚本将运行。如果没有“安装”脚本，那么所有的脚本将在以下步骤中处理…
通过SQL Azure Migration Wizard脚本扫描程序运行脚本文件。(这和测试版一样)
基于扩展中引用的任何程序集检测最小DNN版本。
对于以下每个DNN主要版本{6.0,6.1,6.2,7.0}，如果版本大于检测到的最小DNN版本，执行以下步骤…
创建一个空数据库。
创建一个隔离的用户和模式。
使用上面的模式和对象限定符安装基本DNN数据库对象。
盘点数据库中的所有对象。
使用上面提到的模式和对象限定符，安装扩展SQL脚本。
重新清点数据库中的所有对象。
标识扩展修改过的任何核心数据库对象。
检查该扩展所创建的所有新对象是否正确地使用了模式和对象限定符令牌。
在新创建的数据库对象上运行SQL Migration Wizard，并记录任何SQL Azure兼容性错误。
如果在上面的步骤中没有检测到错误，我们将执行以下步骤，否则扫描将结束。
创建一个新的SQL Azure数据库。
安装基本DNN数据库对象。
安装扩展SQL脚本;检测并记录任何错误。
执行备份;检测并记录任何错误。
将备份恢复到一个新的数据库;检测并记录任何错误。
除了对SQL处理器的更改之外，还有其他一些值得注意的增强:
支持3.0清单(用于DNN 3.0和4.0)。
支持各种扩展组件类型:程序集、认证系统、清理、配置、容器、核心语言、仪表板控制、扩展语言、文件、模块、资源、脚本、皮肤、皮肤对象和小部件。
在扩展中支持多个清单文件。在EVS的以前版本中，如果检测到多个清单文件(。Dnn， .dnn5， .dnn6)，将处理最高级别的清单。EVS现在将处理每个检测到的舱单。这将有助于识别可能特定于某个较低级别清单文件的潜在问题。
添加了一个本地化文件(*.resx)扫描仪，它将检测非utf-8编码的文件，因为如果部署在Azure环境中，它们将导致问题。
还引入了一个将错误链接到外部帮助资源的系统，在接下来的几周内，内容将开始填充和链接。当错误链接到外部资源以获取更多信息时，“更多信息”链接将放置在结果页错误消息的底部。单击该链接将在一个新窗口中打开相关资源。这些外部资源可以是博客文章、维基页面、社区交流项目或论坛帖子。