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

Tweet

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

Advertisement

   

Comments

[Tony]

Since you work on the azure team, you should maybe consider making a custom msbuild task that could verify that the correct references are set to Copy Local and fail the build otherwise. The full set of pre-deployed assemblies is certainly known at build time. Just a suggestion. Thx

[ToddySM]

Tony,
Thank you for the suggestion. It is certainly worth looking at, and I will pass this to the teams responsible for SDK and Visual Studio tools.
HOwever I am not sure that the full set of pre-deployed assemblies is known at build time because you do your build on a local machine but deploy on the cloud. If something exists in your GAC locally this is not guarantee it will exist in the cloud.
Of course this doesn't mean we should not try to make it as robust as possible.

[Magnus Markling]

Hi!
Thanks for these suggestions. Is there no way or plans to support actually viewer what error causes the instance to be cycling? Rather than having to guess what is causing the problem.
Regards
Magnus

[ToddySM]

Hi Magnus,

We are planning to provide more details on what is going on once you start deployment, which will help pinpoint the problem. You should expect to see this in the future.

[Padda]

Hi,

Due to the number of projects in my solution, I've removed references from the Azure WebRole project to the majority of other projects within the solution. I then use a prebuild step to pull the appropriate assemblies into the bin. There's also some dependency injection magic going on in the project. When I publish the project, the assemblies that I pull in during the prebuild aren't in the Azure deployable package.

Other than having to include all refernces to the projects in my solution with CopyLocal=true, is there any other way that will allow additional artefacts to be included within the cspkg file?

[ToddySM]

Padda,

You can use the cspack command line tool to manually create the package and include binaries that you want/need. You can find more information here: http://msdn.microsoft.com/en-us/library/gg432988.aspx