Windows Azure: ‘Roles instances are taking longer than expected to start’

New caching doesn't seem to be a productivity improvement

New caching doesn’t seem to be a productivity improvement

I’ve experience the above plenty of times – hit F5, wait for your projects to build then sit back and enjoy anywhere from a minute to five minutes of peaceful reflection while the Azure emulator gets up to speed.

After some playing with procmon I discovered that the vast majority of activity in those interminable minutes could be put into three broad buckets:

  • Logging to DFAgent.log, sometimes tens of times a second (something I’m seriously considering symlinking to NUL, or at the very least a ramdisk)
  • Various things to do with installing the Windows Azure Cache Emulator
  • Lots of communications with ‘something cloudy’ at 168.63.0.*

Troubles seemed to start with the install of the 1.8 SDK, but in fact appear now to be linked to whether or not ‘Enable Caching’ is turned on in the cloud role properties:



Some timings from my machine on a particularly large solution, from ‘Starting emulator’ to a usable deployment:

  • Enable Caching ‘On’: ~3 minutes average
  • Enable Caching ‘Off’: ~15 seconds average

This is a bugger though, as you can’t have cloud-configuration-specific settings for your caching – it’s either globally on or globally off. In addition, without caching enabled anything that attempts to use it will fail with an exception (fine, if those classes fall back to a null cache implementation). So – for my purposes, my local development environment setup changes from:

  • Caching enabled
  • Use Azure caching for session state management

to a new cloud project specifically for development with:

  • Caching disabled
  • Use the Session State service for session state management (configured in web.config) and web.config transforms to convert to Azure Caching session state management for deployment

And my F5 experience goes from three to five minutes down to 15-20 seconds. Not ideal, as I’ve taken my development environment another step further away from my deployment environment, but from a productivity point of view it’s a no-brainer.

Have yet to diagnose why installing the Windows Azure Cloud Cache components as happens during a development run is so costly – more investigation required…

Proxying Microsoft.WindowsAzure.Storage.Table.CloudTable

The Windows Azure SDK’s pretty good, but implementation decisions in sections of it can make extending or monitoring what it’s up to tricky. Recently I wanted just to track the number of reads and writes that were taking place on a set of tables per request to identify opportunities for caching.

Given I was using a repository pattern, I was able to proxy the CloudTable object upon which queries are executed. While the proxy doesn’t inherit from CloudTable (not least because it’s sealed), with only a couple of lines replaced all code that called methods upon an instance of CloudTable were quickly calling the equivalent methods on my proxy. It’s not perfect, but now that it’s in place I can do a number of fun things like track table storage operation counts, or implement access control per table.

To save anyone else having to write it, it’s presented below:

Windows Azure cache client crashing when developing locally? Check your system time

While trying to diagnose a time-zone issue in an Azure application, I lazily changed my system clock to be an hour earlier instead of actually changing my system timezone. I then found I couldn’t start my app in the emulator:

CacheInstaller.exe has stopped working? Check your system time

CacheInstaller.exe has stopped working? Check your system time

If your system clock is out by more than about 10 minutes and you’re trying to use the Azure cache for development purposes then you’re going to have some trouble.

Remember – having your system time right doesn’t just mean setting it up to look right on the clock in the taskbar, you also need to be in the right timezone so that calculations to and from UTC are performed correctly.

Fun with sometimes.rb – in .NET…

Sometimes.rb is a fun set of helpers that give you the ability to express a degree of fuzziness in your Ruby logic. A couple of examples from the docs:

15.percent_of_the_time do
  puts "Howdy, Don't forget to register!"  # be annoying, but only 15% of the time
(4..10).times do
  pick_nose  # between 4 and 10 boogers made, it's unpredictable!

Given ten minutes and a small Aberlour I thought I’d have a bash at emulating some of it in .NET just for fun:

“Object reference not set to an instance of an object” exception when deploying Azure project


  • Created a new cloud project into which I wanted to deploy an existing bit of code (a new staging service for an existing production system for testing)
  • Right-click Publish… and after a few seconds of thinking deploy fails with NullReferenceException (Object reference not set to an instance of an object exception) and reports of a fatal error but no other diagnostic information

Problem was that the existing service had an HTTPS endpoint defined using a certificate that I’d not uploaded to my brand-new staging service. Deleting the endpoint (or uploading the certificate) does the trick.

Instrument specific types using wildcards with nrconfig

I just pushed version of the NRConfig.Tool NuGet package and the associated project site – the binary is also available as a direct download.

Only two changes:

  • A fix for nested types showing duplicate method signatures in the output XML file
  • Introduction of the /w flag for wildcard matching of type names to be included in the New Relic custom instrumentation file

The /w switch is pretty straightforward – specify one or more wildcard filter strings that identify types to be included in the output file. So, if we had a project using the Repository pattern we could instrument the public methods of all of our concrete repositories:

nrconfig /i MyAssy.dll /f methods+ /w *Repository

which would match any type whose full name ends with Repository. Or we could instrument types in a specific namespace:

nrconfig /i MyAssy.dll /f methods+ /w MyAssy.Utils.* MyAssy.Controller.*

or limit ourselves to specific types:

nrconfig /i MyAssy.dll /f methods+ /w MyAssy.Controller.HomeController

Visual Studio assembly reference details in Properties pane doesn’t match what gets used for the build

Having lost a day to this, I post in the hope someone else gets their projects fixed sooner. Caveat: No idea which step fixed the issue.


  • Large solution (~40 projects) containing multiple Azure services, all targeting Azure SDK 1.7
  • Another team member upgrades to Azure SDK 1.8
  • Now can’t deploy a working build to Azure as once up, site 500s with Could not load file or assembly ‘Microsoft.WindowsAzure.ServiceRuntime’ or one of its dependencies
    • Everything still works just peachy locally, though
  • Right-click… Properties on a Microsoft.WindowsAzure.ServiceRuntime reference in any project, find that the version mentioned is when we’re expecting
    • Even though the .csproj file specifically says the reference is and with a hint-path pointing the right way
    • Where is VS2012 pulling this from?
  • Run build with diagnostic-level logging to find assembly being used in build process even though it’s not part of the .csproj file

Solution for me

  • Close Visual Studio
  • Find C:\Users\USERNAME\AppData\Local\Microsoft\VisualStudio\11.0\Designer\ShadowCache folder, delete all contents
  • Uninstall all Azure SDKs lower than 1.8, and any other associated libraries etc using Add/Remove Programs
  • Remove registry value at key HKLM\SOFTWARE\Classes\Installer\Assemblies\Global\Microsoft.WindowsAzure.ServiceRuntime,version=”″…
  • Use gacutil /u to uninstall the 1.7 assembly from the GAC
  • Restart machine
  • Delete entire source tree from local disk and pull down again from source control
  • Clean solution
  • Rebuild all

Determine element visibility in WatiN with jQuery

This Stack Overflow post by MrBlueSky describes how to determine element visibility in a WatiN test case. As a convenience, here’s that code refactored as an extension method on Browser:

public static class BrowserExtensions
    public static bool IsElementVisible(this Browser browser, Element element)
        var command = string.Format("$('#{0}').is(':visible');", element.Id);
        return browser.Eval(command) == "true";


            using (var browser = new IE(""))
                var page = browser.Page<Login>();



nrconfig – Automatically generating custom instrumentation configuration files for NewRelic with .NET

New Relic’s a pretty good monitoring service and its support for .NET is pretty good – both integrated instrumentation and support for custom runtime metrics.

However, configuring custom instrumentation gets frustrating if you have to instrument more than a handful of methods:

  • You need to specify each method to be instrumented down to the parameter list (if you have method overloads) – this is something of a time vampire
  • There’s no way of saying ‘just instrument everything in this class for me’
  • There’s no link in Visual Studio between the instrumentation config file and your code – refactoring breaks your instrumentation silently

To help, I’ve written a build-time tool that post-processes .NET assemblies and generates custom instrumentation files for NewRelic very quickly. It’s available on NuGet as two packages:

It’s got a GitHub project page that contains documentation and use-cases.

It’s got two modes:

Coarse-grained filtering on the command-line – no code changes required

Here we’re assuming that we don’t want to (or can’t) change the source of the projects we want to appear in the configuration file. The tool has a mode that does a more freestyle reflection over assemblies and generates instrumentation entries for every method (or constructor or property) that matches some very coarse criteria – it’s not perfect, but it’s intended to quickly bootstrap the instrumentation process with a file that can be manually tailored.

The workflow’s very simple:

  • Run the tool, specifying which code elements should be instrumented
    • One or more of {all, constructors, properties, methods}
    • Append + or – to the end of each class of code element to specify inclusion of public (+) or non-public (-) members
    • Use them in combination – for example, methods+- properties+ constructors+ will generate a configuration file to instrument all methods (public or otherwise), and public constructors and public properties
  • Either use the configuration file straight-off, or adjust it manually

Marking up your code with attributes

Need more control? The most fine-grained way to use the tool is to mark up assemblies, classes or methods (with properties and constructors also supported) with an [Instrument] attribute.

  • If you mark up an assembly with the attribute, it’s assumed you want to instrument every method in every class in that assembly – heavy handed but brutally straightforward
  • If you mark up a class with the attribute, it’s assumed you want to instrument every method in that class, and every method in any nested classes
  • You can limit the scope of the attribute to constructors, methods or properties (or combinations thereof), and to public and non-public members in each case

The workflow is still pretty straightforward:

  • Mark up your assemblies, classes or methods with [Instrument] attributes as required
  • Run the tool as a post-build step – it reflects over the assemblies and generates an appropriate custom instrumentation file

Download and Documentation

Binaries are available on NuGet – first, the tool itself (which can then be referred to as ‘nrconfig.exe’:

PM> Install-Package NRConfig.Tool

Then, optionally, the library that contains the [Instrument] attribute that can mark up assemblies, classes and methods:

PM> Install-Package NRConfig.Library

You can also download the tool and optional the library directly.

Documentation is available on the nrconfig GitHub page. Source is available at


New Relic’s instrumenting profiler has some limitations with respect to generics and the tool can’t do much about them:

  • It doesn’t appear possible to specify that a particular method overload should be instrumented if that method overload takes an instance of a generic class as a parameter and the generic class is itself parameterised by more than one type parameter. For example, IEnumerable<string> is fine, but IDictionary<string, string> isn’t as it has two type parameters.
    • The tool handles this by generating an instrumentation entry for all methods with the same name in the same class when a complex (i.e. >= 2 generic type parameters) generic type is detected – it means some methods get instrumented when you don’t want them to, but appears at present to be the only way to get instrumentation to work
  • It’s not possible to instrument generic classes at all.


This project has nothing to do with New Relic the company – it’s neither supported nor sanctioned by them, so if it breaks come crying to me and not the nice folks on their support desk.

Failing to generate WSDL from an Azure-hosted WCF service behind SSL

Error: Cannot obtain Metadata from


  • WCF Service with SOAP, JSON and XML endpoints where the SOAP endpoint is a basicHttpBinding rather than a wsHttpBinding
  • All service endpoints behind SSL
  • SecuritySwitch installed and rewrite rules enabled to force all requests through to SSL where available
  • AspNetCompatibilityEnabled = true, MultipleSiteBindingsEnabled = true
  • <useRequestHeadersForMetadataAddress> element added to service behaviour with default ports http -> 80 and https -> 443
  • Trying to add a service reference in Visual Studio yields a number of errors:

    The document at the url
was not recognized as a known document type.
The error message from each known type may help you fix the problem:
- Report from 'XML Schema' is 'The document format is not recognized 
(the content type is 'text/html; charset=UTF-8').'.
- Report from '' is 
'The document format is not recognized (the content type is 
'text/html; charset=UTF-8').'.
- Report from 'DISCO Document' is 'Discovery document at the URL could not be found.'.
  - The document format is not recognized.
- Report from 'WSDL Document' is 'The document format is 
not recognized (the content type is 'text/html; charset=UTF-8').'.

Bugger. However, notice that the initial request URL is http, and the WSDL endpoint is https. Trying to navigate manually to the ?wsdl URL failed and just re-rendered the ‘You have created a service’ welcome page.


In my case the solution was to set httpsGetEnabled = true (in addition to httpGetEnabled=true) on the serviceMetadata tag for the service behaviour in question.

Hopefully Google’ll find this for me the next time I do it!