Extension Verification Service (EVS) Update

I'm happy to announce that the Extension Verification Service (EVS) has officially come out of beta and that EVS v1.0 is now live. If you haven't already experienced EVS, I recommend taking a look at my first blog post (/Community-blog/cid/147439/Extension-Verification-Service-EVS.aspx). If you trialed the EVS beta and submitted feedback, many thanks for your help. Any additional questions or comments about this most recent release can be posted to the EVS forum at http://bit.ly/evsfeedback.

The most significant changes made to EVS in this release were centered on the SQL Azure compatibility scanner. In the initial release, EVS used the SQL Azure Migration Wizard to scan all the SQL scripts found in an extension. There were two issue identified with this approach:

1. There are some SQL Azure compatibility issues that the Migration Wizard wasn't able to identify by only scanning the script files. For example to detect a missing clustered index, the Migration Wizard could only detect those when processing an actual SQL database.

2. It was unrealistic for extension developers update old, legacy script files to support SQL Azure as changes to upgrade scripts could have unintended consequences for users who might be in the middle of the upgrade path. To solve this it was obvious we needed to add support for Install scripts.

Due to the limitations listed above and a few additional feature request, the entire SQL scanner portion of EVS was rebuilt from the ground up and now includes the following functions.

• Support for rolled up install scripts.

• Detection and warning for modifications done to core database objects.

• Detection and warning for improper/incomplete usage of the {databaseOwner} & {objectQualifier} tokens.

• Detection and warning for any SQL Azure compatibility issues found in the SQL script files.

• Detection and warning for script execution on major versions of DNN in SQL Server.

• Detection and warning for any SQL Azure compatibility issues found in SQL Server.

• Detection and warning for script execution on major versions of DNN in SQL Azure.

• Detection and warning of any issues that might arise during the backup and restore of the SQL Azure database.

The following work flow is used when performing scans for SQL Azure compatibility issues:

1. Identify if the manifest has specified any SQL scripts.

2. Check for an 'Install' script in the list of SQL scripts.

3. If there is an 'Install' script, then moving forward only that script and any subsequent version scripts will be run. If there isn't an ‘Install’ script, then all the scripts will be processed in the following steps...

4. Run the script file(s) through the SQL Azure Migration Wizard script scanner. (This is the same as in the beta)

5. Detect the minimum DNN version based on any assemblies referenced in the extension.

6. For each of the following DNN Major versions {6.0, 6.1, 6.2, 7.0} if the version is greater than the detected minimum DNN version, perform the following steps…

7. Create an empty database.

8. Create an isolated user and schema.

9. Install the base DNN database objects, using the schema and object qualifier from above.

10. Inventory all objects in the database.

11. Install the extensions SQL scripts, using the schema and object qualifier from above.

12. Inventory all the objects in the database again.

13. Identify any core database objects that were modified by the extension.

14. Check to see that all the new objects created by the extension are correctly using the schema and object qualifier tokens.

15. Run the SQL Migration Wizard on the newly created database objects and log any SQL Azure compatibility errors.

16. If no errors are detected in the step above, we will perform the following steps otherwise the scan will end.

17. Create a new SQL Azure database.

18. Install the base DNN database objects.

19. Install the extensions SQL scripts; detect and log any errors.

20. Perform a backup; detect and log any errors.

21. Restore the backup to a new database; detect and log any errors.

In addition to the changes to the SQL processor, there are a few other noteworthy enhancements:

• Support for 3.0 manifest (which is used for DNN 3.0 & 4.0).

• Support for various extension component types: Assembly, Authentication System, Cleanup, Config, Container, Core Language, Dashboard Control, Extension Language, File, Module, Resource, Script, Skin, Skin Object and Widget.

• Support for multiple manifest files in an extension. In the previous version of EVS, if multiple manifest files were detected (.dnn, .dnn5, .dnn6), the highest level manifest would be processed. EVS will now process each detected manifest. This will help identify potential issues that might be specific to one of the lower level manifest files.

• A localization file (*.resx) scanner was added, which will detect non utf-8 encoded files, as they will cause issues if deployed in an Azure environment.

• A system to link errors to external help resources was also introduce and over the next few weeks content will begin to be populated and linked. When an error is linked to an external resource for more information, a “More Info” link will be placed at the bottom of the error message in the results page. Clicking the link will open the related resource in a new window. These external resources could be blog posts, wiki pages, community exchange items or forum posts.

I hope these enhancements are helpful and again welcome any feedback which can be posted on the forum located at bit.ly/evsfeedback. And if you’re new to EVS, be sure to check out evs.dnnsoftware.com.