If you’ve been working with Azure Web Roles and deployed them to an Azure subscription, you likely have noticed the substantial size of a simple web role deployment package. Even with the vanilla ASP.NET sample website the deployment package seems to be quite bloated. This is not such a problem if you have decent upload bandwidth, but in Australia bandwidth is scarce like water in the desert so let’s see if we can compress this deployment package a little bit. We’ll also look at the consequences of this large package within the actual Web Role instances, and how we can reduce the footprint of a Web Role application.
To demonstrate the package size I have created a new Azure cloud service project with a standard ASP.NET web role:
Packaging up this Azure Cloud Service project results in a ‘CSPKG’ file and service configuration file:
As you can see the package size for a standard ASPX web role is around 14MB. The CSPKG is created in the ZIP format, and if we have a look inside this package we can have a closer look at what’s actually deployed to our Azure web role:
The ApplicationWebRole_….. file is a ZIP file itself and contains the following:
The approot and sitesroot folders are of significant size, and if we have a closer look they both contain the complete WebRole application including all content and DLL files! These contents are being copied to the actual local storage disk within the web role instances. When you’re dealing with large web applications this could potentially lead to issues due to the limitation of the local disk space within web role instances, which is around the 1.45 GB mark.
So why do we have these duplicate folders? The approot is used during role start up by the Windows Azure Host Bootstrapper and could contain a derived class from RoleEntryPoint. In this web role you can also include a start-up script which you can use to perform any customisations within the web role environment, like for example registering assemblies in the GAC.
The sitesroot contains the actual content that is served by IIS from within the web role instances. If you have defined multiple virtual directories or virtual applications these will also be contained in the sitesroot folder.
So is there any need for all the website content to be packaged up in the approot folder? No, absolutely not. The only reason we have this duplicate content is that the Azure SDK packages up the web role for storage and both the approot as well as sitesroot folders due to the behaviour of the Azure Web Role Bootstrapper.
The solution to this is to tailor the deployment package a little bit and get rid of the redundant web role content. Let’s create a new solution with a brand new web role:
This web role will hold just hold the RoleEntryPoint derived class (WebRole.cs) so we can safely remove all other content, NuGet packages and unnecessary referenced assemblies. The web role will not contain any of the web application bits that we want to host in Azure. This will result in the StartupWebRole to look like this:
Now we can add or include the web application that we want to publish to an Azure Web Role into the Visual Studio solution. They key point is to not include this as a role in the Azure Cloud Service project, but add it as a ‘plain web application’ to the solution. The only web role we’re publishing to Azure is the ‘StartupWebRole’, and we’re going to package up the actual web application in a slightly different way:
The ‘MyWebApplication’ project does not need to contain a RoleEntryPoint derived class, since this is already present on the StartupWebRole. Next, we open up the ServiceDefinition.csdef in the Cloud Service project and make some modifications in order to publish our web application along the StartupWebRole:
There are a few changes that need to be made:
- The name attribute of the Site element is set to the name of the web role containing the actual web application, which is ‘MyWebApplication’ in this instance.
- The physicalDirectory attribute is added and refers to the location where the ‘MyWebApplication’ will be published prior to creating the Azure package.
Although this introduces the additional step of publishing the web role to a separate physical directory, we immediately notice the reduced size of the deployment package:
When you’re dealing with larger web applications that contain numerous referenced assemblies the savings in size can add up quickly.
But what does WebRole.cs contain?
Good question, it contains a class that inherits from the RoleEntryPoint class. Although not required you can use it to create your event hooks for configuration changes.
Hm. Can you described more?
This is very interesting and useful topic! I noticed too that resulting packages contains my application twice and was wondering for a while how to get rid of such duplication.
In the post you describe the result but not the process to achieve it 🙂 Please.
Apologies if the article was a little unclear, I’ve made some amendments so please have a read through again. In summary your solution will contain a ‘stripped down’ web role and you package up your actual web application in the ServiceDefinition file.
Appreciate the addition! And sorry for a long response, missed reply notification.
FYI after some testing, ive found that simply editing your serviceconfiguration.csdef by:
– renaming your “Web” site to anything else
– adding the physical path to this node
will do the same thing as outlined in this article.
Super duper helpful