Azure Emulator not working with SQL server alias

I just spent a few hours trying to figure out something that had me stumped.

In my local dev environment I’m building a web api which has a SQL database. The connection string for the database is an alias with a named pipe. If I set the web api as StartUp project in Visual Studio it works fine. (See this post for some tips on how to do that). But when I’d instead start the Azure emulator as the StartUp project it wouldn’t connect to the sql server, with the good ol’:

A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: SQL Network Interfaces, error: 26 – Error Locating Server/Instance Specified)

Eventually I figured it out. The alias was the problem, because if I changed the connectionstring to .\sqlexpress it worked fine.

Digging deeper, the problem was I had set up the alias on the “SQL Native Client 11.0 Configuration (32bit)” node, but I hadn’t added an alias on the “SQL Native Client 11.0 Configuration” node. So the fix was to create an additional Alias on the “SQL Native Client 11.0 Configuration” node.


So it seems that debugging a web api locally may be a 32 bit process but debugging with the Azure emulator is a 64 bit process. Maybe?

Anyway, hope this helps someone.


Generating Swagger example responses with Swashbuckle

Update May 4th 2017: I have created a new NuGet package called Swashbuckle.Examples which contains the functionality I previously described in this blog post. The code lives on GitHub.

I have also created a .NET Standard version of the NuGet package at Swashbuckle.AspNetCore.Examples, which is also on GitHub.

Swashbuckle is a tool for generating Swagger, the API description language, from your ASP.NET Web Api solution.
Using Swashbuckle, which provides Swagger-UI, you can create pretty living documentation of your web api, like this:

Documenting the Response

In this post I am going to show you how to document the Response, and a new way to generate some response examples.

You can specify the type of response for Swashbuckle a number of ways. Consider a simple API endpoint which returns a list of Countries:

public class CountriesController : DefaultController
    public async Task<HttpResponseMessage> Get()
        var resource = new List<Country>
            new Country {Code = "AR", Name = "Argentina"},
            new Country {Code = "BR", Name = "Brazil"},
            // etc etc omitted for brevity

        return Request.CreateResponse(HttpStatusCode.OK, resource);

One way of describing the response code and content for Swashbuckle is using a combination of XML comments, and the ResponseType attribute, like so:

/// <response code="200">Countries returned OK</response>
public async Task<HttpResponseMessage> Get()

However, this only allows for one type of response.

If your API method can return multiple types, i.e. in the case of an error, then you can use the new SwaggerResponse attribute:

[SwaggerResponse(HttpStatusCode.OK, Type=typeof(IEnumerable<Country>))]
[SwaggerResponse(HttpStatusCode.BadRequest, Type = typeof(IEnumerable<ErrorResource>))]
public async Task<HttpResponseMessage> Get(string lang)

The Swagger 2.0 spec allows for examples to be added to the Response. However, at time of writing Swashbuckle doesn’t support this. Fortunately Swashbuckle is extendible so here is a way of doing it.

Install my Swashbuckle.Examples NuGet package.

Decorate your methods with the new SwaggerResponseExample attribute:

[SwaggerResponse(HttpStatusCode.OK, Type=typeof(IEnumerable<Country>))]
[SwaggerResponseExample(HttpStatusCode.OK, typeof(CountryExamples))]
[SwaggerResponse(HttpStatusCode.BadRequest, Type = typeof(IEnumerable<ErrorResource>))]
public async Task<HttpResponseMessage> Get(string lang)

Now you’ll need to add an Examples class, which will implement IExamplesProvider to generate the example data

public class CountryExamples : IExamplesProvider
    public object GetExamples()
        return new List<Country>
            new Country { Code = "AA", Name = "Test Country" },
            new Country { Code = "BB", Name = "And another" }

And finally enable the ExamplesOperationFilter when you configure Swashbuckle’s startup.

    .EnableSwagger(c =>

Now that we’ve done all that, we should see the examples output in our swagger.json file, which you can get to by starting your solution and navigating to /swagger/docs/v1.


And then, when you browse the swagger-ui at /swagger/ui/index, instead of an autogenerated example like this:
response old

You’ll see your desired example, like this:
response new

Be sure to check out Part 2, where we again use Swashbuckle to generate example requests.

Run a Windows Azure cloud service locally without the Azure compute emulator

A big bugbear when developing Azure cloud services is the Azure emulator. You make a code change and the write – compile – debug process is slowed down big time because you have to wait for the Azure emulator to start up every time.

One project I worked on had a Web API running in an Azure cloud service and an ASP.NET MVC website running in another cloud service. So in order to develop it locally we had to run 2 instances of Visual Studio 2013 and each of them would fire up an emulator. Needless to say this was quite the resource hog and we’d every now and then see unexpected issues with Visual Studio or the emulators. Oh and the emulators would fight over which ports they would run on so we had to ensure we started debugging the API first so that it would get port 443 and then start the website which would default to 445.

So why can’t we just install our Web API and ASP.NET MVC website into IIS and not use the emulators? Well there are two blockers:

  1. The Azure diagnostics config will throw exceptions if we’re not running in Azure
  2. Settings are read from cloud config values in ServiceConfiguration.cscfg via RoleEnvironment.GetConfigurationSettingValue which needs Azure

My colleague Dylan came up with a solution. Basically, in the Global.asax.cs of both our website and our web api, we need to check if we’re running in Azure or not.

If we are in Azure, then use 1. configure Azure diagnostics config, and 2. read cloud config values using the default RoleEnvironment.GetConfigurationSettingValue.

If we are not in Azure, then 1. don’t configure Azure diagnostics, and 2. read cloud config values from ServiceConfiguration.cscfg manually via XML. parsing.

if (RoleEnvironment.IsAvailable) // we are in Azure
    Trace.Listeners.Add(new DiagnosticMonitorTraceListener());
    Trace.AutoFlush = true;
    var di = new DirectoryInfo(HttpContext.Current.Server.MapPath("~"));
    var solutionRoot = di.Parent;

    var xdoc = XDocument.Load(solutionRoot.FullName + @"\Identity.Web.Azure\ServiceConfiguration.cscfg");
    ConfigurationSettingsProvider.Current = new NotInRoleEnvirovmentConfigurationProvider(xdoc, "Identity.Web");

Our ConfigurationSettingsProvider.Current is by default a DefaultConfigurationSettingsProvider which uses RoleEnvironment.GetConfigurationSettingValue(key) to read the cloud config – we use one of these when we’re in Azure.

Our NotInRoleEnvirovmentConfigurationProvider reads the .cscfg file using XDocument.

So now I can install our website and web api into IIS locally – and code changes are visible after a compile. No need to run 2 Visual Studios and wait for the memory hungry emulator to startup every time. If I need to debug I can Debug -> Attach to process. Much more productive :-)

Should I cycle: on hold for now

I started building a prototype for Should I cycle on iOS 8 and pretty early on I’ve hit a roadblock. What I wanted was a daily scheduled notification to popup telling me whether conditions were right for cycling or not.

I wanted to use iOS’s local notifications to do this – but I don’t think it can be done. Sure, you can schedule a local notification to popup at say 7:30am, but what’s displayed on the notification has to be set at the time the notification is scheduled. What this means is let’s say at 9pm at night I schedule a notification for 7:30am the next day. And at 9pm the sky is clear and conditions are fine. Then at 7:30am the next day it’s raining. Well, the 7:30am notification popup is going to say “Sky is clear” because that’s what the conditions were like when the notification was scheduled.

So that’s annoying.

What I want to do can be done via remote notifications – i.e. the I would have to schedule on a web server a push notification out to the mobile at 7:30am the next day. But that would be pretty complicated to setup for a prototype.

So I decided I would give up on the push notification for now and instead just check the current weather / cycling conditions whenever the app is started.

But then another thing happened – I gave up cycling to work for various reasons. So for now I have no motivation to work on this app. Maybe one day I’ll pick it up again.

Browse and debug an Azure web role website running locally on a mobile device

So, you’re developing an Azure website using a Web role, and now you want to see what that website looks like on a mobile device.

First, follow my instructions here to set up port forwarding for your website.

Once you’ve done that, assuming your mobile device is on the same network as your PC running the Azure web role, you should just be able to open the URL for the website in your mobile web browser – in my case this

If you need to debug the traffic between your Azure web role and the mobile device, you can do that using Fiddler or Charles proxy. Fiddler instructions here. Charles instructions here. And SSL instructions for Charles here, if your site runs on SSL.

If you need to manipulate the traffic between Azure and the mobile browser, you can use Fiddler’s custom rules to do that – in my case I had to inject a “IsMobile=true” header. Fiddler -> Rules -> Customize Rules. Locate “static function OnBeforeRequest” and add the following line to it. oSession.oRequest[“IsMobile”] = “true”;

Should I cycle: designing the UI

This is the sixth post in my series on building a mobile app, “should I cycle”.

Now that I’ve got my API implemented I’m ready to build the client app.

For my initial prototype I don’t really need any UI at all – I can get away with hard-coding the values I want for my should I cycle alerts particular to my route – e.g. 8am, London, no rain, not easterly winds over 10 mph. However, I haven’t gotten around to implementing that yet for one reason – I can’t decide whether to implement an iPhone or Android (or even Windows Phone) version first. See, I currently have a 2 year old iPhone 5 which is working fine. Just last week the new iPhone 6 was released and I was a bit underwhelmed, so I probably won’t be buying one. So right now I can’t decide whether to stick to my iPhone 5 or jump over to Android and get myself a OnePlus One phone which my flatmate owns and looks pretty good.

In the meantime I started thinking about what the UI for a first version of Should I cycle could look like, and came up with these mockups (using Balsamiq). As you can see I’ve taken iOS’s Alarm app as inspiration and copied much of its UI.

01 Home

02 add alert

03 repeat

04 label

05 city

06 Pollution

07 weather

08 wind direction

09 wind speed

Hmm I guess right now I should just get on with a prototype (with no UI) on iOS for my iPhone 5!

Should I cycle: implementing the API using Node.js

Now that I have my API defined, and it is pretty darn simple, it’s time to implement it.

During my day job I write ASP.NET MVC websites and Web APIs, but part of the reason for doing a side project such as this is the chance to dabble in different technologies.

Since my API is so simple I thought I’d give it a go using Node.js.

I found this nice tutorial which got me started.

As per my API documentation, my endpoint will look like this:


My API is going to:

  1. Take two arguments
    1. weather location
    2. air quality monitoring locations (a list)
  2. Call an external API for each of those arguments
  3. Parse the results from those external APIs into a result and return it.

Since Node is all about doing stuff in a non-blocking parallel way, I have to make each of the external API calls in parallel. And since the air quality argument is actually a list of locations, I can call each one of them in parallel too. I came across the async library and a helpful post by Sebastian Seilund on how to use it. Basically, I can use async.parallel to start two tasks – one which looks up the weather, and the other which calls async.forEach to lookup the air quality (also in parallel!).

The results of each of these are collated into an object named shouldicycle and returned via JSON.

router.get('/v1/cycle', function(req, res, next) {
    var location = req.query.location;
    var airQualities = req.query.airquality;
    var shouldicycle = {};
    shouldicycle.pollution = [];

        // Get weather
        function(callback) {
            if (location) {
                weather.lookupCurrentWeather(location, shouldicycle, callback);
            else {
        // Get airquality
        function(callback) {
            if (airQualities) {
                var airQualityArray = airQualities.split(',');
                async.forEach(airQualityArray, function(airQuality, airQualityCallback) {
                    weather.lookupAirQuality(airQuality, shouldicycle, airQualityCallback);
                }, callback);
            else {
    // This is called when weather and airquality are done
    function(err) {
        if (err) return next(err);

Anyway, that’s enough source code for one blog posting.
The entire source is in github over here. All of the logic lives in server.js and weather.js. Code reviews are welcome, this is my first node app :-)

Debugging node

I developed the shouldicycle API on a mixture of Mac and Windows machines, but when it came to debugging I found good old Visual Studio 2013 with Node.js Tools for Visual Studio to be perfect for the job. Not sure what I would do if I had to debug my node app on my Mac.

Deploying it to Heroku

Since I am in Node land I decided to deploy it to Heroku. I could have deployed it to Azure, but since deploying to Azure is part of my day job I thought I’d see how Heroku works.

I found this helpful guide on deploying a node app to Heroku.

So yay, my minimum viable product API is up!

Here’s a sample query for London:,uk&airquality=WA7,WA9


There’s still plenty to be done on that API. A bit of validation and checking on the input parameters for a start. And to implement caching too, both of my results and also of the results I retrieve from the weather and pollution APIs. But what I’ve done so far is enough for a minimum viable product, so now I can move on and get started with the iOS / Android app.