DotNetNuke on Azure – Not Quite Ready

For kicks, I decided to try setting up DotNetNuke on Microsoft Azure.  The idea of a DNN install with all the high availability features of Azure is pretty intriguing. With SQL Azure CTP, it’s now possible to migrate a ‘classic’ SQL Server database to the cloud and run it on an infrastructure that is almost identical to SQL Server 2008.   I say almost, because there’s actually a few differences in what’s supported.  Fortunately, there is already a migration wizard available. 

So, I ran the wizard against a DNN database and tried running the scripts against my SQL Azure CTP database.  Unfortunately, it wasn’t quite that simple.  There were a few bugs in the wizard, and a few items it didn’t catch.  In the end, I took the script that it generated and ran it using SQL Management Studio (which incidentally is not as straight-forward as it sounds), and fixed errors as I found them. The most common errors were regarding string literals as column names.  Instead of this:

SELECT ‘MyColumnName’ = (SELECT COUNT(*) FROM …) FROM …

SQL Azure would rather you do this:

SELECT MyColumnName = (SELECT COUNT(*) FROM …) FROM …

Also, there were a fair number of errors about references that include the database name or schema, so instead of this:

SELECT * FROM database.schema.table

SQL Azure would rather:

SELECT * FROM table

With those and a few other errors out of the way, I finally got the database installed.  I scripted the data from my local DNN database using SQL Management Studio and ran that as well.  Finally, I tweaked the DNN Web Site’s connection string, and… got a nice yellow screen of death:

I’m pretty sure this is related to the way Enterprise Library Data Access Application block ‘discovers’ SQL Parameter types.  If they aren’t fully provided in the app, then .NET will query the database for metadata and use the metadata to build up SqlParameter instances.  Well, it turns out SQL Azure doesn’t support this yet either – which explains why SQL Management Studio’s Object Browser can’t connect to it- it uses the same metadata to show you all the tables, procs, etc.

So, that’s where it stands for me.  It’d be technically possible to write DataProvider that gets around these limitations.  I may play with that concept, but since future versions will have more SMO support, I’m not sure it’d be worth the effort.  More interesting would be moving to the cheaper and infinitely scalable Azure Tables and Blobs.

So, this has been a good learning experience.  I think SQL Azure will be a nice way to ease existing apps into the cloud. It’s definitely CTP bits, but things more or less work like you’d expect.  Stay tuned for more as SQL Azure progresses.