Composite Windows Azure Webrole version is released.

We have released our Composite Windows Azure Webrole version In this blog post I will tell you alittle about it and how you build it from source and deploy it to azure with or without SSL support.

Composite Windows Azure Webrole

At Composite A/S we have had this webrole since 2011, but some months ago we decided to refactor what we allready had and we are close to being ready to replace the old bits with the new. We are already running with it and start of october this year we was testing it out in a scaleout setup for This scaleout setup is something new we have added. This post is the introduction to How we used Composite Windows Azure Webrole for hosting (Link Coming) for this years event where the site was hitting more than 120 requests per secound at peak hour in a scaleout setup.

We are going to distibute the webrole as nuget packages where consumers can add their own logic to the webrole if needed and as precompiled packages ready to deploy on Windows Azure. We will be distributing sample configurations at the github repository So if you want to configure some addition settings or change the webrole code, you can grap the latest release from github and deploy your package directly from visual studio.

Where are websites stored

The webrole needs a Windows Azure Blob Storage to store configuration files and websites as we are using Windows Azure Cloud Services to host the websites on IIS. We will cover the configuration settings when we have understood how the webrole handle websites. Websites are located in the Blob Storage and when the webrole start up it will sync down all configured websites and set them up on IIS. This means you can host multiply websites in the same webrole if you want to. When the webrole have setup all sites it will move from the OnStart() to the Run() state. Each website can be configured in two modes, either in writeback mode or not. When a website is in writeback mode it will write changes done on the local file system to the remote blob storage according to aset of upsync rules. The default upsync rules are as below and in one of the coming versions these will be changeable.

  new NoSyncDamperRule("*.tmp"),
  new NoSyncDamperRule("*.lock"),
  new NoSyncDamperRule(@"App_Data\Composite\Cache\*"),
  new NoSyncDamperRule(@"App_Data\Composite\ApplicationState\*"),
  new NoSyncDamperRule(@"app_offline.htm"),
  new NoSyncDamperRule(@"App_Data\Composite\LogFiles\*"),
  new NoSyncDamperRule(@"App_Data\Composite\DataStores\Composite.Data.Types.IUserConsoleInformation_Published.xml"),
  new NoSyncDamperRule(@"App_Data\Composite\DataStores\Composite.Data.Types.IFlowInformation_Published.xml"),
  new NoSyncDamperRule(@"App_Data\Composite\DataStores\Composite.Data.Types.ILockingInformation_Published.xml"),
  new SlidingWindowSyncDamperRule(@"App_Data\Composite\Packages", TimeSpan.FromSeconds(60), TimeSpan.FromSeconds(15)),
  new SlidingWindowSyncDamperRule(@"App_Data\*", TimeSpan.FromSeconds(10), TimeSpan.FromSeconds(1)),
  new SlidingWindowSyncDamperRule(@"bin\*", TimeSpan.FromSeconds(10), TimeSpan.FromSeconds(1)),
  new SlidingWindowSyncDamperRule(@"*.*", TimeSpan.FromSeconds(10), TimeSpan.FromSeconds(5)),
  new NoSyncDamperRule(@"App_Data\Composite\Configuration\C1ConsoleAccess.xml")
  Snippet 1: Upsync Rules, where the first argument is the regex for file matches, the second is the max time to wait before doing a sync and the thrid argument is the cooldown period.

When the website is not in writeback mode, then it will reflect the remote blob storage and downsync any changes when trigger files have a their ETAG changed. So simply touching a trigger file will make the webrole go up and check what have been changed and download the changes only. The default trigger files are:

  StoreTriggers = new List<WebsiteChangeTrigger> {
    new WebsiteConfigurationChangeTrigger(),                
    new WebsiteFileTouchedTrigger(LAST_SYNCHRONIZED_FILE) 
  Snippet 2: The trigger files for websites, where LAST_SYNCHRONIZED_FILE is “LastSynchronized.txt” and the first one is monitoring the configuration file for a website. All trigger files are within the website configuration folder in the blob storage.

Windows Azure Blob Storage

When deploying the Composite Webrole, you need to configure a blob storage also and a deployment container name, otherwise it wont work. The deployment container name is the container where the webrole will create its configuration files. If it do not exist, it will be created when starting up and sample configuration files will be created with examples of configuration. With the current version a configuration folder will be created with a websites.xml file and an example can be seen here with the configuration from

<?xml version="1.0" encoding="utf-8"?>
  <Website name="kn-website-131007" storename="kulturnatten-website-130904"/>
  <!--Give each website a unique name, namespacing.-->
  <!--Set storename to the container that holds the website-->

The name should be unique and it will also be the folder name that the webrole will use for storing the site on the server at c:\www\<name>. The storename is another container on the same blob storage account with the website configuration and website files.

Caption: The content of the Website Container, a websites folder with is all the website files. Diagnostics contains files that the C1 Package Composite.Azure.Publisher uses for showing status. Configuration folder contains settings and this is also the location for the LastSynchronized.txt file that is monitored for checks. This file is touched when the Publisher has pushed files.

Inside the Configuration Folder for websites, you can find WebsiteConfiguration.

<?xml version="1.0" encoding="utf-8"?>
  <!--Set runtime Writeback to true or false :>
  <Runtime writeback="true" />
    <!--<binding port="80" hostname="" certificateHash="hash"> -->
    <Binding port="80" />
  Snippet 3: An example of the configuration file for a website. We see the runtime element with the writeback attribute, this is the two modes introduced earlier. And bindings, where was configured to bind against port 80 on all hostsnames. The webrole also supports SSL and the thumbprint of the certificate to use can be specified with the certificatieHash attribute.

So from the deployment container you can specify website containers, and from website container settings for the website can be specified. This way, it is easy to move websites from one webrole to another. Hopefully this also makes it easy for web agencies to setup environment for easy staging and tests when creating websites. Setting up such their websites are deployed to Windows Azure Blob Storage and the Composite Webrole will take care of the rest.


We are using Windows Azure Diagnostics for all trace logs and diagnostics in the webrole, so if you already are familier with this and have tools for viewing logs, then you are all set. If you havent used this before, then we recommand Azure Management Studio from Cerabrata. Note that with the newest Visual Studio 2013, you get some debugging utilities inside visual studio. More info on this topic later. 


In near future we will as before provide precompiled packages ready to deploy on Windows Azure, but for now you can test and use this by creating your own packages. This also makes it easy for you to configure Remote Desktop access from Visual Studio and with the integration that have been made with Visual Studio 2013. You will be able to use earlier versions of Visual Studio also, but there are less integration with Windows Azure. Only requirement is having the Windows Azure 2.2 SDK installed.

To get started. Take a look at for two already configured projects. You only have to update the settings. You can also use the issue tracker on github for this project for questions and bugs related to the webrole. Hope you will like it. I will soon publish a blog post with more specific information about how we hosted kulturnatten and what options you have with Composite Windows Azure Publisher and Webrole. 

comments powered by Disqus