Snip/Shot by Toddy Mladenov

Windows Azure deployment – did you forget to pack your DLLs?

OK, back to the topic deployment stuck in Initializing, Busy, Stopping! One more thing you can do is to crack-open your package and look inside if you have all the necessary DLLs. Thanks to Jim who send me the note, and has a good post how to look inside the service package.

Deploying Package with Missing DLLs on Windows Azure

Using the steps he describes in his post I created simple project. The app does nothing but shows static text. For the purpose of this exercise I have initially set Copy Local attribute for the following DLL to false:

 

Microsoft.WindowsAzure.Diagnostics 
 

After clicking Publish on the project I got the following in the output windows:

 

C:\Program Files (x86)\MSBuild\Microsoft\Cloud Service\1.0\Visual Studio 10.0\Microsoft.CloudService.targets(0,0): warning : CloudServices44 : Forcing creation of unencrypted package.

This is the guarantee that I have the package unencrypted, and will be able to look inside. Note: Please keep in mind that you will not see this warning in Visual Studio 2010 Beta because a bug.

In order to look in the package I had to change the extension of the package file from CSPKG to ZIP.

 

The next thing I had to do is to extract the CSSX file for the Web Role, and change its extension to ZIP. Just for your information Web Roles and Worker Roles are packed in CSSX files and stored in the main folder of the package file. The name of the file is the same as the name of the role you give in Visual Studio (in my case this was SimpleWebRole) followed by underscore and GUID.

 

 

If my dependencies were packed in the CSPKG file I would expect to see them in the following folder:

 

<%Role_Root%>/approot/bin

 

Of course, because I have set the Copy Local attribute to False, the diagnostics DLL was not there.

 

 

Deploying the package works fine, however trying to run it puts it in an endless loop between Initializing-Busy-Stopping:

 

 

 

Great! I managed to hose my deployment completely

Adding the DLLs to the Package and Re-deploying

Now, let’s get back to Visual Studio and change the Copy Local attribute for Microsoft.WindowsAzure.Diagnostics to True. Using the same steps as above I verified that Microsoft.WindowsAzure.Diagnostics.DLL was added to my package.

 

Deploying the package and running it produces the desired result – after some time I can see my role in Ready state and can load the default page of my simple application.

 

Few More Tips

As Jim mentions in his blog post Windows Azure service packages come in two flavors – the single file version and the CSX folder structure under the Visual Studio project. If you build your project and look in the following folder:

 

<%Project_Root%>\bin\Debug\[Project Name].csx

or 

<%Project_Root%>\bin\Release\[Project Name].csx

You will find your roles and the corresponding approot\bin folder underneath. If all necessary DLLs are in this folder they will also be packed in the single file version package that is normally deployed. In my case this was:

 

<%Project_Root%>\bin\Debug\Crack-Open Demo.csx

Important: You need to make sure that each role contains the necessary DLLs in its own approot\bin subfolder. The reason for that is that each instance of each role is deployed on a separate VM, and if those are missing the role will be cycling. 

Here are the links to my other posts that will hopefully help you resolve your deployment issues:
Windows Azure Deployment Stuck in Initializing, Busy, Stopping – Why?

Using Windows Azure PowerShell Sample to Investigate Issues with Cycling Roles

Guidelines for Specifying Windows Azure OS

Few days ago Windows Azure announced version 1.1 of Windows Azure OS and judging by how fast the announcement of Operating System Versioning in Windows Azure picked up on Twitter month and a half ago, I think the interest in the feature will be quite high. In this post I would like to give you some more details on what to look for, when selecting Windows Azure OS version.

Why versioning Windows Azure OS in first place?

The reason Windows Azure gives you the option to specify the OS for your guest VM is quite simple – you should be able to test your application before the OS it is running on gets updated. Although the believe is that minor updates of the OS should not break applications (and this may be the case in majority of the cases) there is still the risk that something may not be working after the upgrade. This problem becomes more severe when major upgrades come into play – then you need to have this option for sure.

Of course there is also the other camp – what about bug fixes and security updates for the OS? It is a fair point that those are important too, but here is the question to ask: “Would you rather have application that doesn’t work and is secure or have application that works but is insecure?” There is no right answer for that. Or I would rather say, the right answer is: “I would like to have application that is secure and works.”

Having in mind that Windows Azure OS is still quite “young”, giving the control to the customer may not be such a bad idea. The best approach though would be to have at least the option to choose some level of auto-upgrade (on a patch level or minor version level). Of course this will come soon as the team recognizes the need for that.

How to specify Windows Azure OS Version?

As you can read from the MSDN documentation you can set the osVersion attribute in the service configuration (CSCFG) file if you want to specify the Windows Azure OS Version for your VM. In order to find out what are the possible values for osVersion attribute you need to look at the article specific to the OS version you want. The best starting point is the OS/SDK Compatibility Matrix - all Windows Azure OS versions are listed in the navigation tree under that article.

 

 

The osVersion attribute accepts values in the following format:

 

WA-GUEST-OS-M.m_YYYYMM-nn

 

Where:

• WA-GUEST-OS is a fixed string
• M.m are the major and minor versions
• YYYY is the year
• MM is the month
• and nn is a sequence number used to differentiate releases within a month if necessary

 

This string is mapped to user friendly string with the following format:

 

Windows Azure Guest OS M.m (Release YYYYMM-nn)

 

Where all the letters have the same meaning as above. Examples for osVersion attribute value and friendly name are:

 

WA-GUEST-OS-1.0_200912-01
Windows Azure Guest OS 1.0 (Release 200912-01)

 

What happens if you don’t specify Windows Azure OS Version?

There are several options to update the CSCFG file and hence to specify the osVersion attribute in it. However, if you don’t specify OS Version in your CSCFG file a “default” version will be selected for you, and osVersion attribute will be added to your service configuration file. This happens in the following cases (either through the Portal UI or through the management APIs):

• When you create new deployment
• When you change your service configuration
• When you upgrade deployment (see below for this one!)

Upgrade deployment is a special case tough, because you can upgrade the whole service or just one specific role. If you upgrade the whole service the behavior is the same as for new deployment and change of configuration. If you upgrade only particular role from the service then your OS version will not be changed. The reason for that is that OS version applies to the whole service, and not to a particular role.

What “default” means is up to Windows Azure team to decide. In general the goal is to have the latest version as default but this is not guaranteed.

Other things to watch for when specifying Windows Azure OS Version

Besides the security patches and bug fixes there is one more thing quite important to watch for, when specifying OS version for your VM. This is the OS/SDK compatibility as described in the MSDN article Windows Azure OS Versions and SDK Compatibility Matrix.

Sometimes features exposed through the SDK may need specific OS in order to work – good example for this is XDrive that was released with the latest SDK. If for example you want to use XDrive in your application you need to target Windows Azure OS 1.1 because it will not work on the earlier version.

Using Windows Azure PowerShell Sample to Investigate Issues with Cycling Roles

After posting Windows Azure Deployment Stuck in Initializing, Busy, Stopping – Why? two weeks ago, I received quite useful feedback from colleagues in our support centers. It is related to the problem with the missing DLLs that may cause your role to be cycling between those states.

 

Retrieving a List of Available DLLs on the Guest VM

If you want to check whether particular DLL is available on the VM your role is running on, you can use the PowerShell sample that comes with the SDK.  In order to do that you need to deploy the sample, and type the following command in the script box:

 

dir d:\ -include <name of file> –recurse

 

If for example you want to check whether System.Data.DLL is available on the VM you should type:

 

dir d:\ –include System.Data.DLL –recurse

 

and somewhere in the results you will see something like this:

 

Directory: Microsoft.PowerShell.Core\FileSystem::D:\Windows\assembly\GAC_64 \System.Data\2.0.0.0__b77a5c561934e089

Mode    LastWriteTime         Length     Name

----    -------------         ------     ----

-a---   4/11/2009 4:12 PM     3008512    System.Data.dll

 

This means that System.Data.DLL is available in D:\Windows\assembly\GAC_64 folder. You can ignore the majority of the output that shows “access denied” because you don’t have access to those folders anyway.

 

OS Version Dependencies

One thing to pay attention here is the OS version dependency. As you already know Windows Azure introduced Operating System Versioning in Windows Azure back in December 2009 (I may post some OS specific clarifications in the future), and there may be differences in the DLLs included in the different OS versions.

Make sure that you deploy the PowerShell sample on a VM that runs the same Windows Azure OS version as your application.

 

Checking References in Visual Studio

Here is one more way you can use to check whether the DLL is available on the VM. If you reference DLLs from .Net Framework 2.0 or 3.5 you can be sure those are available on the VM. You can check this in Visual Studio with expanding the References node under your role and selecting particular reference. In the Properties window find the Path property, and verify whether it is under one of the following folders:

 

C:\Windows\Microsoft.NET\Framework\

C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\

If the reference does not point to a DLL under one of those two folders you need to set the Copy Local property to true.

 

Special thanks to Kevin W. from Microsoft support center in Las Colinas and William B from Microsoft support center in Charlotte for this information.