Azure Compatibility : What does it mean?
There are many moving parts to Windows Azure. Not all the features of Azure are leveraged by DNN installs. You can also create DNN websites in Windows Azure in a variety of ways.
This page specifically lists compatibility with Azure in the way that is performed using the DNN Azure Accelerator.
Specifically, this includes:
- SQL Azure compatibility for the database layer of DNN
- Compatibility with using an out-of-process Caching Provider such as AppFabric for cached objects.
More information :
Create a DNN site on Azure with the DNN Azure AcceleratorOther possibilities for Azure usage includes Azure Websites and using Azure VMs to create DNN sites. They are out of scope for this particular page.
Intended Audience for this information : Any DNN Extension author, whether an extensions vendor, open-source developer, commercial developer or hobbyist.
Once an Extension has been verified to be Azure compatible, the DNN Manifest file should be modified with the
element. From DNN 7.1 onwards, installations based on SQL Azure will check for this element and warn upon installation if it does not exist. See Azure Compatible Extension Manifest Changes
Further Links:
DNN Azure Compatibility FAQ
Azure Compatibility Check
SQL Azure Compatibility for DNN Extensions
SQL Azure is the managed database service on Windows Azure. It provides a highly-available database environment where the implementation details of servers, fail-overs, availability groups, storage and other features are abstracted away, leaving the end-use to consume a fully functional scalable database service with minimal administration requirements, for a very low entry price. The inherent economic advantages and strategic advantages of hosted databases generally, and of SQL Azure specifically, virtually guarantee that it will become a large part of the future of DNN databases.
While SQL Azure is built on top of SQL Server, the features are not exactly the same - this is partially because SQL Azure is a simplified service, partially because the implementation details are abstracted away, and partially because it has higher coding standards to ensure that badly written code cannot destabilize the system.
The master list of supported syntax for SQL Azure is here : Supported Transact-SQL Statements for SQL Azure
The features NOT supported for SQL Azure is here : SQL Azure feature limitations vs SQL Server
The most common items that show up as problems with in DNN Extension Compatibility are:
- Specifying 'PRIMARY' for Tables and Indexes
- Marking a SQL statement with 'NOT FOR REPLICATION'
- Tables missing a Clustered Index (All SQL Azure tables must have a clustered index)
Of course, there are many different problems that may show up. This list shows some of the most common concerns when developing:
- Column alias – Select ‘xx’ = colA is not allowed, instead: Select colA AS ‘xx’
- Create Table… - ON PRIMARY is not allowed as there is no concept of file groups
- Every table needs a clustered index.
- Keywords deprecated: NOT FOR REPLICATION, PAD_INDEX = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, NOT FOR REPLICATION, ROWGUIDCOL.
There are three different ways that SQL Azure problems can surface:
1. At module installation (any invalid Syntax will be rejected and cause the install to be aborted)
2. At module run-time or backup (any conditions not allowed by SQL Azure will be rejected and cause an exception)
3. When restoring a backup (any objects created from a backup that are not valid will be rejected and the backup will not be able to be restored).
The reason there are 3 different categories is that SQL Syntax can surface at different times - and any installed Syntax can always be changed at runtime.
There is more information on SQL Azure compatibility at the SQL Azure Compatibility Wiki page.
Checking existing modules for SQL Azure compliance
EVS
DNN has created a system called EVS (Extension Verification System) which processes a DNN extension and checks it for various things, one of which is compatibility with SQL Azure. This will ensure that a module passes the first test of SQL Azure compatibility, which is being able to be installed.
More Information on EVS
Check your Extension with EVS now
EVS will catch and help to fix most of the obvious problems. However, to guarantee that a module is fully SQL Azure compatible,
Testing against a SQL Azure database
The most complete test for SQL Azure compatibility is to install the module against a site which is using SQL Azure as the underlying database. You can easily build a site yourself using the DNN Azure Accelerator - you can get a Windows Azure Free Trial for 3 months which is very easy to configure and use for testing purposes.
Once you have an example site up and running, there are 4 basic checks to make:
- Installation (this is a re-run of the EVS test and should pass)
- Use - you need to use the extension that is being tested to make sure all of the tables contain data and all stored procedures/queries are run
- Backup - run a backup (to .bacpac format) from your SQL Azure database.
- Restore - run a restore of your .bacpac file to ensure that the restore works correctly.
If your extension passes all these tests, you can be assured that it is fully SQL Azure compatible.
Azure Caching Provider
Windows Azure provides high-performance caching options which can be leveraged by DNN sites. However, this may require some modification of the code within an extension to ensure that any classes used with the cache or session will work as expected.
More information : Windows Azure .NET caching how-to guide for developers
Note : Not all DNN sites running on Windows Azure will use the Windows Caching Provider, but it is recommended that developers familiarize themselves with this requirement, as some sites (such as those delivered through DNN Cloud Services) use Azure caching by default).
Azure caching provides .NET developers with a high-performance out-of-process cache that can be leveraged for high-availability, multiple instance sites. This type of caching is superior in performance to the traditional on-premise DNN caching providers like the File Based caching provider or Web Request Caching provider. It is likely that administrators interested in deploying their sites to Windows Azure (or even other cloud based environments) will be interested in leveraging these tools.
In order for extension code to be compatible with out-of-process caching, it is a requirement that any cached objects (or objects placed into a session object, though this is discouraged) are binary serializable. This means the object can be serialized to a memory strream and deserialized back again as an object.
For simple types like strings, integers and the like, this capability is built-in. However, for complex types like classes, serialization must be explicitly stated.
More information : Binary Serialization in .NET
This is generally done with a Serializable() (C#) or (VB) attribute on the class, or at the level of each individual public property.
Testing Extensions for Compatibility with Out-of-process Caching Providers
There are two tools available for DNN developers to ensure their code is compatible with out-of-process caching providers.
The first is the Cachemaster project, which is a Cache inspection tool for DNN. This module lists all the individual objects that are currently stored in the DNN cache, and provides a True/False feedback for binary serialization with each item in the cache. This can be used for a quick visual check that items fail a serialization check, and to bring to attention any part of your module that requires attention.
To use the Cachemaster project, download the installation package and install it on any site that is running your Extension. Then add a new page for cache inspection (generally this should be an admin /host page if it is a public site) and add the module to that page. The results can be filtered down for cached objects associated with the specific extension being tested, which then reveals the type and key that the object is being stored in the cache with.
More information : Cache Master for DNN
The second tool useful for testing Cache Compatibility is the Dummy Serialization Provider. This module completely replaces the standard Caching provider for DNN with one that requires objects to be binary compatible. If any DNN extension tries to insert an object that isn't binary serializable, the caching provider will throw a detailed exception explaining which piece was incompatible. The Dummy Serialization Provider is NOT for use on production or live sites as it is designed as a development tool which will stop the site completely when an incompatibility is found.
More information : DNN Dummy Caching Provider
The best process is to start with the Cachemaster, identify any problem areas, fix them in the code, and then install the Dummy Caching provider to do a final check on compatibility. If the code runs OK with the dummy caching provider, then it is compatible with out-of-process caching such as used within Windows Azure.