This last week, I have been concentrating my free time in Azure. I found the cloud will provide developers in a common deployment story where all apps should go. Moving from a normal ftp and app to have to use a complete SDK is a mindset that shouldn’t be that difficult to accomplish, yet I have been straggling on the steps and processes.
After installing the Azure tools for Visual Studio 2008 I find VS a little slower than already was, yet I believe that should be resolve on the release of those tools. Good enough now for the deployment.
I found a problem on dll dependencies, if a library referenced on the WebRole has dependencies, they won’t be copied or packaged for the deployment, you’ll have to manually reference those dlls on the GAC on the WebRole and make sure to change the properties to copy locally. A nice feature to ask the Azure team is a dependency test when the system Initialize the application, so the user can see what is missing.
Converting httpHandlers to run under IIS7
Scott Watermasysk post talks about the concept and compares different clouds. A great read.
So, let’s deploy an application.
Starting your web application could take almost 10 minutes to start a WorkersRole and a WebRole could take up to 10 minutes.
A problem for me right now is if the application does not work, there is no way, that I know, to check on the error on the page. The only messages you’ll receive is if you set the error key on the web.config to Off. Yet if the application does not even start, you do not have a Windows log where to check.
When deploying a web app, you first need to deploy it into a test account called “Staging”. Azure will prove you with a GUID link for you to test it, when happy with the results, you can click a button to move it to production, the application will be moved to the permanent URL.
Change your configuration file to work in Azure
Before deploying the application, you’ll have to go to your file ServiceConfiguration.cscfg and add you configuration found on the portal. Warning, Azure won’t tell you forget to add the configuration, only if its incorrect. So make sure you add something on that file.This is what confused me, if you add the configuration you’ll get the error below, if you do not add anything, you won’t get any error. The error below complains about the key names, not the values of those.
<ServiceConfiguration serviceName="CloudServiceForFS" xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceConfiguration"> <Role name="WebRole"> <Instances count="1"/> <ConfigurationSettings> <Setting name="AccountName" value=""/> <Setting name="AccountSharedKey" value=""/> </ConfigurationSettings> </Role> <Role name="WorkerRole"> <Instances count="1"/> <ConfigurationSettings> </ConfigurationSettings> </Role> </ServiceConfiguration>
Error Publishing the Azure App
Error 1 The "CSPack" task failed unexpectedly.
System.IO.IsolatedStorage.IsolatedStorageException: Unable to determine the identity of domain.
Existing bug on Azure discussion: Using too much memory?
Get around the bug by using the cspack command-line instead of VS2008 Publishing. CSPack Command-Line Tool
Another error running the app System.BadImageFormatException: Could not load file or assembly (…)
Compile your dlls in 32bits to avoid the problem of running them on 64bits.
I found another problem with existing dlls that I deployed to Azure. They are always compiled to target any CPU, so if the computer is a 64bits will run in that environment, now, looks like there is a problem/bug in running in 64bits. So I had to force those dlls to run in 32bits.
Could not load file or assembly XXXX or one of its dependencies. An attempt was made to load a program with an incorrect format
This may occur on a 64 bit machine running .net 2.0. They always need to be run in the 32 bit runtime. "BadImageFormat" is referring to the format of the dll, it means .net tried to load a 32bit only assembly into the 64 bit runtime.
To get around this, your application needs to be compiled for 32 bit mode, so it will never be loaded in the 64 bit runtime.
Select 'x86' for your application so that it will always be loaded in 32 bit runtime.
Only managed code
Azure only works with managed .NET Frameworks 2.0 and 3.5, if you have C++ dlls that you compiled on .NET to use DCOM, they won’t work in Azure. You’ll have to use the Amazon cloud. This is a huge limitation for existing applications wanted to move to Azure. Let’s face it, 80% of the customers for Azure are developers trying to move their application to Azure instead of refactoring or creating new applications.
I did waste a great amount of time, deploying the app to find something wrong. The idea of testing the app running on your computer as running in the cloud is great, yet, when packaging the application to run in Azure does not get a copy of the application and its dependencies, so what run on your computer, is not what you are deploying to the server. So, what’s the point of running it on your computer? Azure should make deployment simple and robust, I hope those bugs and problems are fixed by the release version.