Azure Web Sites is a new offering from Microsoft under their Windows Azure cloud platform. It’s a scalable solution that allows you to host ASP.NET, PHP, and node.js projects. If your needs are basic, your sites – up to 10 of them – can be hosted for free*. If you need something like a custom domain, you’ll pay a bit more – currently about $8/mo. If you’d like a reserved instance, rather than shared, that will kick it up to around $70/mo. But you can run several of your web sites on that one reserved instance.
*bandwidth and database sold separately see site for details
The awesome thing is that you can start with the free setup, get up to 10 web sites going and, if your needs grow, scale your web sites up by simple dragging sliders in a web portal. It’s all very simple and straightforward and seems to work well.
One of the first things I tried with the free Azure Web Sites preview was hosting an eXpressApp Framework ASP.NET solution and database. While there are a few gotchas that came with publishing my XAF project to Azure Web Sites, most were the sort of issues you’d work through publishing an XAF ASP.NET project to any new server. However, there are some Azure-specific steps needed to work through some of these, which I’ll cover towards the end.
To get started, head to the Windows Azure homepage and sign up for Azure Web Sites. Afterwards, visit the Azure management portal. Note that after signing up for Azure Web Sites you’ll be treated to a nice new HTML5 UI for the Azure management portal (unfortunately the database management portal is still Silverlight).
Once you are in the management portal, click WEB SITES on the left, then click the NEW button at the bottom-left of the portal. Select the CREATE WITH DATABASE option (no I’m not yelling, the site is covered in caps).
After the process completes, you’ll be left at the DASHBOARD screen for your new web site. On the right, under quick glance, click Download publish profile. This is the file you’ll use in Visual Studio to publish your XAF ASP.NET project. Next, click View connection strings and note the ADO.NET connection string for your Azure database instance.
As a final step in the Azure portal, scroll down the DASHBOARD page and click the link to your database under linked resources. Click the MANAGE button at the bottom of the portal. This should prompt you to add your current IP address to the firewall rules so that you can access the SQL database. Click YES.
Next, if you haven’t already, you’ll want to download and install the Windows Azure SDK.
Now we can jump into Visual Studio and start the process of setting up the XAF ASP.NET project for hosting in Azure. First, double-click the WebApplication.cs file in the Web project. Select the Sql Connection and then edit its ConnectionString property, using the ADO.NET connection string from above. Make sure you use your real password as that will not be shown in the portal.
With the new connection string in place, and with the firewall rule added from the steps above, you should now be able to click Start to debug your XAF ASP.NET project, and successfully run against the new Azure database. This step will also create the destination database schema within the database hosted on Azure.
With these changes in place, right-click the Web project and click Publish. Click the Import button on the first screen and import the publishing profile you saved from the Azure portal.
Aaaand YSOD! Here’s where a bit of troubleshooting comes in. Some of this will be similar to publishing an ASP.NET XAF project to any host. Start by disabling Custom Errors in your web.config and Publish again.
Now you should see that the problem is that the DevExpress ExpressApp assemblies are not on the server.
Aaaand YSOD! Even after setting all of the assemblies explicitly referenced by the ASP.NET project to Copy Local, there are missing ExpressApp assemblies.
Some assemblies – for instance DevExpress.ExpressApp.Security and DevExpress.ExpressApp.Objects – are not explicitly referenced by any of the XAF projects (mentioned to DevExpress here). While this may be addressed by DevExpress in a future update, in the meantime you’ll need to explicitly add any references with the Add Reference dialog, set Copy Local to true, Publish, and repeat on YSOD.
At this point, the ASP.NET XAF app should run properly hosted in Azure Web Sites.
But, there’s one last “gotcha” I want to cover, as trouble-shooting this is specific to Azure Web Sites. If you encounter the generic XAF ASP.NET error, you’ll need access to the XAF log to troubleshoot.
This may happen, for instance, if you make use of the HTML property editor in your ASP.NET solution and have not published all of the required assemblies.
To access the XAF log, go back to the Azure management portal. Click on the link under FTP HOSTNAME, which is in the quick glance column of the DASHBOARD.
You’ll be prompted for a username and password. You can get these by editing the PublishSettings file (downloaded above) in Notepad. Look for the userName and userPWD values after the FTP publishMode.
Once you’ve logged in, you’ll have full FTP access to both your sites and any logs. Navigate to site, then wwwroot. You should see an eXpressAppFramework.log file.
View the file’s contents, and search for “error occurred”. This will help you find XAF errors that occur that don’t cause a YSOD. This can and will happen for missing assembly references, such as DevExpress.SpellChecker.Core, if you use the HTML property editors.
With connection strings in place and all of the proper assemblies referenced and published, XAF ASP.NET projects run quite well in Azure Web Sites.
I’ve been using Azure Web Sites for a couple of months to host both my personal website and the website for Hip Shot and have been very pleased overall. And, if you don’t need a custom domain or a reserved instance, your web site hosting is free – bandwidth and database storage aside.