Recently, I've been able to divert from my normal Store activities and work on a project that I feel will have a big impact on the platform, community, Store and the overall DNN ecosystem. This project is the Extension Verification Service (EVS). EVS attempts to simplify the extension development and testing process by automating some of the initial compatibility checks. Currently EVS conducts this compatibility checking by focusing on three key areas which include the package manifest, SQL scripts and assemblies.
First, EVS checks the extension to ensure that it is complete and well-formed. This process first extracts the extension then checks for the existence of a .dnn manifest file. Once it finds the manifest file, it will then check that file for completeness and correct form. If optional sections are missing, it will issue a warning for each one. If required sections are missing, it will issue an error message for each missing section. Over the next few weeks we also plan to add support for the legacy manifest used before version 5. We also plan to add a two-way file check that ensures that every file listed in the manifest is included in the extension package and conversely that every file in the package is accounted for in the manifest. I know there have been times in the past that I've included a new file in an install package and neglected to add it to the manifest file. Another item that we would like to add in the near future is the ability to link the most common errors reported by EVS to respective areas in the wiki to help quickly inform users what can be done to correct the issues.
The second area that EVS will check for compatibility is the data layer. If the extension has SQL scripts, it will scan and parse the SQL looking for primarily for SQL Azure compatibility issues. With the push to make DNN SQL Azure compatible, there have been some issues raised by early adopters of DNN on the Azure platform. Many third-party extensions and even some of the core extensions have had issues with the SQL scripts that keep them from installing correctly on SQL Azure. In an attempt to make SQL server scale better in a cloud environment, Microsoft has removed some functionality from the typical SQL server feature set when they developed the SQL Azure platform. Many of these differences are difficult to identify. There is already a project in CodePlex (
sqlazuremw.codeplex.com) that attempts to ease the process of moving from SQL server to SQL Azure. We used this project as a basis for our SQL scanner with a few extra methods on top to help track the changes and to handle locating the scripts in the extension. Over the next few weeks, we also plan on expanding the functionality of the SQL scanner by returning a zip file which contains the SQL Azure compatible versions of the scripts found in the extensions. Another check that we would like to add to this area of EVS in the future is a check that ensures the proper usage of {databaseOwner} and {objectQualifier}. We would also like to add a function that will check to ensure that the uninstall script will correctly remove all of the objects added by the installation scripts.
The third area the EVS will check for compatibility is the assemblies. If the extension has assemblies, it will scan them looking for potential assembly reference errors, and to determine based on assembly references the minimum required DotNetNuke version and the minimum required .Net version. This part of the system relies on reflection to examine the references of each assembly included in the extension. That list of references and versions are then compared against a known list of .Net and DotNetNuke assemblies for each version of the respective platforms the system can then determine from that the minimum required version of both the .Net and DotNetNuke platform needed for the extension to run correctly. Over the next few weeks we will expand upon this functionality to also track each reference to ensure that they are either included in the .Net GAC, DotNetNuke or are included in the extension. If not we will then return an error to alert the user to a potential assembly reference error.
With all the functionality already included in EVS and the functionality that is already planned to be added over the next few weeks EVS will be a useful tool to help developers and users to evaluate the compatibility of extensions. However, it's important to note that this is not a certification system. Just because an extension doesn’t return errors from the EVS system, there is no guarantee that the extension will be problem free. EVS is also not a replacement for proper testing and traditional safeguards like performing a back-up when installing new extensions. The purpose of the current beta test is for people who have recently experienced compatibility issues to submit the extensions in question and see if EVS is able to identify the potential issue. If issues have been identified, it would be very helpful to bring those to our attention so that we can see if there is a way for EVS to automate the detection of that issue in the future.
Hopefully you will find this utility to be useful and I welcome any feedback regarding EVS. Feedback can be left via the forum located at
bit.ly/evsfeedback and the EVS site is located at
evs.dnnsoftware.com