DNN has been Azure compatible since version 6.0, when a concerted effort was made to make sure that all the underlying core DNN database code was made compatible with SQL Azure.    This early foray into hosting DNN sites on Azure was further improved with the release of the DNN Azure Accelerator, which started with DNN 6 and continues to the current day.

More recently, DNN is now available on Windows Azure Websites as a very simple installation, which you can get on a free Azure trial.  

[You can watch a video from Joe here on installing Windows Azure Websites, and sign up here for a Free Trial]

Windows Azure itself is growing strongly, with Microsoft recently releasing some heady figures:

- Customers doubled in the last 12 months

- 1,000 customers a day sign up for Windows Azure accounts

- Compute and storage size doubles every 6-9 months

I first started looking at DNN and Azure back in 2010 when Azure was in it’s infancy and getting a DNN site to run properly in the cloud was a large challenge – to see figures like the ones above shows just how much ground has been covered in a very short time.  From a standing start to a billion dollar business in a handful of years is something we should all take not of.

DNN and Windows Azure are complementary technologies – Azure provides the flexible, powerful, true cloud solution and DNN provides the flexible, powerful and extensible platform to build great applications.   

With the growth of Azure and an increase in the number of ways in which DNN can be run on Azure, a problem has been increasingly appearing – that many DNN Extensions are not compatible with SQL Azure, and installing an incompatible Extension can lead to a site in which the module is in an unstable state and not easily uninstalled.

We on the cloud and platform teams at DNN have heard about this from customers, developers, partners and drive-by commenters.   It’s a problem that needed to be addressed, so the DNN 7.1 release includes a change designed to both mitigate this problem and raise awareness of the need for developers to test their code against SQL Azure if there is any possibility it will be run in the cloud.   This applies to open-source contributors, commercial vendors and in-house developers.

SQL Azure Incompatibilities

I’m not going to run into the ways in which SQL Server and SQL Azure are different – there are syntax differences, run-time differences and differences in the way backups and restores (actually called ‘exports’ and ‘imports’) are done.   Incompatibilities can show up at installation time (when database creation scripts are run), at run time (when code is executing) or at backup/restore time.

You can dive deeper into SQL Azure Compatibility (and contribute) at the SQL Compatibility Centre on the DNN Wiki.

The Azure Compatible Manifest Check

Starting from DNN 7.1, there is a new manifest element that can be included with the package of a DNN Extension.   This is a simple true/false marker of whether or not the module has been tested and verified to work with SQL Azure.

Including the Check in the Manifest file is simple, just add it as a child of the element:

You don’t need to make up a specific DNN 7.1 Manifest file – it can be added to an existing DNN manifest file (version 5).  However, the element will only be read by DNN 7.1 or later, and will only affect sites running 7.1 or later on sites using SQL Azure as a backend.

Azure Compatible Check Logic

The logic for the check is very simple:

• If the DNN Installation is NOT running on SQL Azure as a database, it will install as normal
• If the DNN Installation is running on SQL Azure as a database and the Extension is marked as Azure Compatible, it will install as normal.
• If the DNN Installation is running on SQL Azure as a database and the Extension is either marked as not being Azure Compatible, or does not include any indication of Azure Compatibility, a warning will be shown to the user while installing, and will require them to verify that they wish to continue with the installation.

The warning shown if the site is running on SQL Azure and the element is missing or set to false looks like this (final wording may change):

The person installing the extension has to manually verify that they wish to proceed – the installation can proceed.

This information will be kept up to date and improved through the Azure Compatible Element Wiki Page.

It is vitally important that developers do not mark a module as compatible unless it has been tested and verified as being compatible with SQL Azure.

SQL Azure compatibility testing is easily done using the Extension Verification Service.

Conclusion

This change is one that is not taken likely – backwards compatibility is a strong goal with all DNN releases.  However, the opportunities that Windows Azure brings with it also bring up some challenges, and ensuring end-users are aware of the differences and the potential for problems is important to maintain the overall quality experience that people have come to expect with DNN.

If you have any questions around this change, please ask through the comments below.