Patterns and practices relating to programming.

Receiving Webhooks With IIS Express

One of the projects I’m currently working on is using a service that reports various events back to our system via webhooks. Since the features I’m working on aren’t ready for deployment yet I was looking for a decent way to test the integration in my development environment to ensure that I’m not only receiving the correct data but also that I’m handling it properly.

The service’s documentation recommended pointing the webhooks to another service such as RequestBin to inspect the contents. I did mess around with that approach for a bit and although I was certainly able to see the requests in the RequestBin log and push them on to the application with fiddler, it really didn’t seem like an adequate solution and I was tired so I went to bed.

It turns out that sleeping on it was exactly what I needed. Sometime overnight I subconsciously worked out a better solution; I could open up IIS Express to handle remote connections and configure NAT on my router to forward requests for that port directly to the IIS Express instance. It turns out that getting all this working was actually quite simple.

Allowing Remote Connections

Allowing remote connections to IIS Express requires a little work but it’s pretty straight-forward and is outlined in this stackoverflow post. In short we need to:

  1. Create an additional IP binding for the IIS Express site to allow traffic from all hosts.
  2. Allow connections to the port from anyone
  3. Create a firewall rule to allow traffic to the port on the development machine

Creating an IIS Express Binding

IIS Express sites are managed per-user. To create the IIS Express binding we simply need to create a new entry for the site in the configuration file located at %userprofile%\documents\iisexpress\config\applicationhost.config. In the file locate the site then duplicate the binding, changing the allowed host to *. For example, if the current binding is:

I’ve used port 99999 in these examples for demonstration purposes only. You’ll want to use the port listed in your configuration file.

<binding protocol="http" bindingInformation="*:99999:localhost" />

You’d create a copy and change localhost to * such that it reads like this:

<binding protocol="http" bindingInformation="*:99999:*" />

It’s very important that you leave the original binding in place. Yes, it is redundant to have a binding for all hosts and another for only localhost but Visual Studio uses the localhost binding to initialize IIS Express. If that binding isn’t present Visual Studio will create a duplicate site entry and you’ll likely start seeing errors such as the one pictured below.

URL Binding Failure

URL Binding Failure

Setting Security on the Port

Once you’ve created the IIS Express binding you need to allow connections to the port. This is done by executing target=”_blank”>netsh to add a URL reservation for the new binding. In this case we’ll be using netsh http add urlacl to register the address we bound to the IIS Express site and granting permission to everyone.

netsh http add urlacl url=http://*:99999/ user=everyone

Note that “everyone” refers to the Everyone group in Windows. If you’re using a non-English version you’ll need to change that to the localized name for your language.

Creating a Firewall Rule

The final step is allowing traffic to that port through the local firewall. Accomplishing this varies according to which firewall solution you’re using. For Windows firewall you can control this through the control panel or by executing the following netsh command which changes some advanced firewall configuration settings.

netsh advfirewall firewall add rule name=”IISExpressWeb” dir=in protocol=tcp localport=99999 profile=private remoteip=any action=allow

Configuring NAT

Configuring NAT is not something I can really help with in this article because each environment will have its own instructions and restrictions. For me and my home office network it was easy because I simply had to add a custom application that referenced the configured port and host machine in my router’s firewall configuration.

Alternatively, I could have configured the IP Passthrough to route traffic to the development machine but I deemed this to be too much exposure to the outside world and left it with NAT.

Accepting Webhooks

Once I’d configured everything on my network to accept the webhook traffic I went to the external application’s dashboard and registered my computer as a webhook recipient using the WLAN IP address I obtained from my router’s status page and the port I bound to IIS Express for the application. I then set a breakpoint in the webhook processing logic, ran the application, made a change in the remote system to initiate sending an event, then watched in amazement as my breakpoint was hit and the watch window showed data received from the remote service.

Mission accomplished.


Changing the Default TFS Check-in Action

It’s been a number of years since I worked with TFS. Now that I’m back in that world one of the things that has bitten me is that by default any tasks tied to a check-in are resolved by default. Automatically marking tasks as complete has left me scratching my head in bewilderment as I wondered why a task I’m actively working on was no longer listed under my tasks. I can see the utility of this behavior in some circumstances but I often make incremental check-ins as I work through more complex tasks so clearly I don’t want checking in my changes to automatically close the task.

Since relying on my memory to change the check-in action from Resolve to Associate clearly isn’t adequate here I looked for some way to change the default behavior. I found that there are two ways to achieve this, neither of which are obvious.

The first method is to remove the Microsoft.VSTS.Actions.Checkin action from the work item template. The other method applies only to the client machine but requires a registry edit. Neither option is particularly great but given that the first option requires you to have authorization to modify the template and applies to each user of the template, I opted for the second approach.

To disable the default resolution option you need to locate HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\12.0\TeamFoundation\SourceControl\Behavior\ResolveAsDefaultCheckinAction and change the ResolveAsDefaultCheckinAction value from True to False. After making the change, restart Visual Studio and the Associate should now be selected the next time you try adding a work item to the check-in.

ResolveAsDefaultCheckinAction option

Clean Code, Evolved

Bob Martin’s 2008 book, Clean Code, is considered by many to be one of the “must read” books for software developers, and for good reason: The guidelines discussed in the book aim to decrease long-term software maintenance costs by improving code readability. One of the most beautiful aspects of Clean Code is that although it was written with an emphasis on Java development, the guidelines are applicable to software development in general.

Clean Code was written to combat the plague of unmaintainable code that creeps into software projects. You know the kind: intertwined dependencies, useless comments, poor names, long functions, functions with side-effects, and so on. Each of these things make code difficult to read but some are more nefarious because they make code fragile and difficult to reason about. The end result is code that is difficult and expensive to maintain or extend.

In March I had the good fortune to speak at Nebraska Code Camp. I was really excited about the way the schedule worked out because I was able to sit in on Cory House’s talk about Clean Code. As Cory walked through the points I remembered reading the book and pondered its impact on how I write code. Eventually, my thoughts drifted to the climate that necessitated such a book and its continued relevance today. In the days following Cory’s talk, I reread Clean Code and further developed my thoughts on these subjects. (Confession: I skipped the chapters on successive refinement, JUnit internals, and refactoring SerialDate this time around.) What I came to realize is that while the Clean Code guidelines are an important step toward improving code quality, many of them simply identify deficiencies in our tools and describe ways to avoid them. Several of the guidelines gently nudge us toward functional programming but they stop short of fixing the problems, instead relying on programmer discipline to write cleaner code.

There is no doubt that understanding and embracing the Clean Code guidelines leads to higher code quality but relying on developer discipline to enforce them isn’t enough. We need to evolve Clean Code. (more…)

String Calculator TDD Kata in F#

In a recent post I mentioned that I started learning F#.  Over the past few weeks I’ve really started falling in love with the language.  Coincidentally, my team has been incorporating more test-driven development (TDD) into our process and as part of that training Roy Osherov’s TDD Kata 1 was mentioned.  I immediately thought “Hey! Let me try doing that in F# and see how it goes!”  I’ve run through the kata more than a few times now and I’m ready to share my experience with the world. (more…)

NUnit With F#

Visual F#A few weeks ago I started learning F#. As I moved from the simple examples that were easily executable in F# Interactive or LINQPad though I found myself wanting to write formal unit tests to make sure I was understanding the concepts correctly. I decided to write my tests in F# for more practice and because its syntax makes it an attractive choice but in order to keep the learning curve under control a bit I thought it best to stick with a familiar test framework – NUnit. Using NUnit with F# is pretty trivial but being so new to the language I ran into a few small obstacles.

Importing Types

In order to use NUnit we need to import the types from the NUnit.Framework namespace. Importing the types is accomplished with the open keyword which looks and behaves much like the using directive in C#.

open NUnit.Framework

Don’t get too excited yet though because the compiler is probably yelling at you.

Most F# tutorials that I’ve seen provide examples that are easily run within F# Interactive (FSI), LINQPad, or a single F# Application (exe) project. They generally only include a few types and almost never span multiple files let alone multiple assemblies or languages. This is great for introducing concepts but as soon as you move to a more complex library project (like one for testing) the compiler will politely inform you of a problem depending on where you’ve placed the declaration:

Files in libraries or multiple-file applications must begin with a namespace or module declaration, e.g. ‘namespace SomeNamespace.SubNamespace’ or ‘module SomeNamespace.SomeModule’

If you’ve placed the directive at the beginning of the file before declaring a namespace or declaration you’ll see the above error. To fix this problem I like to take the namespace route because I’m just trying to group my testing types and it follows the organization pattern I’d be using were I writing the tests in C#.

namespace StringCalculatorKata.Logic.Tests

open NUnit.Framework

type StringCalculatorTests() =
  member x.Add_EmptyString_ReturnsZero() =
    // Test Code Omitted
  [<TestCase("1", Result=1)>]
  [<TestCase("2", Result=2)>]
  member x.Add_SingleNumber_ReturnsThatNumber calcString =
    // Test Code Omitted

Applying Attributes

With the types imported we can identify our fixtures and tests. The good news is that we accomplish this with attributes just like with other .NET languages. The bad news is that although it’s simple, it’s not immediately obvious. If you’re reading this you should already know that TestFixtureAttribute applies to the classes that hold your tests and that TestAttribute and TestCaseAttribute identify tests. But how does that translate to F#?

One answer is to define a type and decorate it with the appropriate attributes. You’ll want to make sure you’re applying the test attributes to member bindings rather than let bindings here because let bindings compile to internal members whereas member bindings compile to public members by default.

type StringCalculatorTests() =
  member x.Add_EmptyString_ReturnsZero() =
    // Test Code Omitted
  [<TestCase("1", Result=1)>]
  [<TestCase("2", Result=2)>]
  member x.Add_SingleNumber_ReturnsThatNumber calcString =
    // Test Code Omitted

Were you aware though that since .NET 2.0 you could apply TestFixtureAttribute to a static class as well? If you prefer this approach you can define your fixture as a module since modules compile down to static classes.

module StringCalculatorTests =
  let Add_EmptyString_ReturnsZero() =
    // Test Code Omitted
  [<TestCase("1", Result=1)>]
  [<TestCase("2", Result=2)>]
  let Add_SingleNumber_ReturnsThatNumber calcString =
    // Test Code Omitted

Aside from being a module definition, notice that the attributes are applied to let bindings in the module. Module level let bindings compile to public static members by default.


So far I’ve been careful to avoid including assertions in the sample code. Not to worry, assertions in F# are the same as they’d be in any other language but you do need to be aware of a syntactic nuance that affects many of the assertion methods.

In short, the compiler’s overload resolution mechanism requires you call them using a syntactic tuple form (syntax that looks like a tuple but isn’t) rather than the curried form that’s so common in F#. This means that instead of separating the individual parameters with spaces you need to call the method like you would in C#:

type StringCalculatorTests() =
    member x.Add_EmptyString_ReturnsZero() =
        let calc = new StringCalculator()
        let result = calc.Add ""
        Assert.That(0, Is.EqualTo 0)

Of course, if you’re using TestCaseAttribute with the optional Result parameter you’ll be able to eliminate the manual assertion altogether in many cases:

type StringCalculatorTests() =
  [<TestCase("1", Result=1)>]
  [<TestCase("2", Result=2)>]
  member x.Add_SingleNumber_ReturnsThatNumber calcString =
    let calc = new StringCalculator()
    calc.Add calcString

Moles vs Fakes: The Differences

If you’re a fan of the Microsoft Moles framework you’ve probably heard that it’s being included in Visual Studio 2012 as Microsoft Fakes.  As I was preparing my talk covering this isolation framework I noted some of the key differences between the two.  Rather than going back and updating my original post regarding Moles (much of which is still applicable even with terminology changes) I thought I’d list those differences here.  So without further ado:

  • Assembly generation is driven by a .fakes file rather than a .moles file
  • Isolation types are placed in a .Fakes assembly and .Fakes namespace
  • Shim types replace Mole types
  • Stub types are prefixed with “Stub”
  • Shim types are prefixed with “Shim”
  • ShimsContext replaces HostTypeAttribute for enabling profiling
  • Profiling occurs in the IntelliTrace profiler rather than the Moles profiler
  • Fakes allows shims for static constructors whereas Moles allowed erasing static constructors through an assembly attribute
  • Fakes does not provide any support for finalizers whereas Moles allowed erasing finalizers through an assembly attribute
  • Moles allowed controlling whether the profiler would run as a 32-bit or 64-bit process but this is now handled entirely by the IntelliTrace profiler
  • The “classes” filter attribute was removed.
  • Fakes supports isolating auto-implemented properties
  • Fakes play much nicer with testing frameworks other than MSTest when run through Visual Studio

Upcoming Talks

If you’re interested in learning about the Fakes framework (formerly Microsoft Moles) that’s included with Visual Studio 2012 you have two opportunities to do so this week.  Those in Fort Wayne, Indiana should attend tomorrow’s (June 12) NUFW meeting.  If Indianapolis is more convenient, feel free to attend Thursday’s IndyNDA meeting instead.  Of course, if you just want to heckle me attending both is also an option!

If either of these events interest you please check the appropriate group’s site for logistics.  I hope to see you there!

Speaking in Fort Wayne

Ok, this should be the last post about speaking engagements for a while ;)  I have something else in the works that’s going to take a lot of my attention for some time (more on that on Friday). 

I’m pleased to announce that I’ll be returning to Fort Wayne in June to talk about the Microsoft Fakes framework (formerly the Moles framework).  In this talk I’ll introduce the Fakes framework, discuss the use cases for the different isolation techniques, and show how to take advantage of them in your unit tests.

The meeting will be held on Tuesday, June 12 at the Northeast Indiana Innovation Center.  Pizza and drinks will be available at 6:00 with the presentation starting at 6:30.  For more information please check the NUFW site.

TortoiseSVN: Extended Context Menu

I’ve been using TortoiseSVN for years.  One place I’ve found it lacking in the past though was when I wanted to remove unversioned files from my working copy.  This has generally been a nuisance but I’ve dealt with it.  A few days ago, I needed to recover from a merge gone wrong and got serious about finding a better way.


IndyNDA – Testing Code From The Pit Of Despair

It’s the second week of February so if you read this blog with any frequency you know what that means.  That’s right, IndyNDA is this Thursday (9 February)!  This month we’re fortunate to have Phil Japikse returning to discuss testing legacy code.

Michael Feathers defines Legacy Code as any code that doesn’t have automated tests, and you agree that automated tests are an important facet of successful software development. Then it happens – you get your next assignment, and it’s your worst nightmare! You have to maintain and enhance a large application that has no tests in place, and there are parts that are just plain scary. Where do you start? Traditional Test Driven Development techniques don’t typically work, since they focus on an inside-out development paradigm.

I will show you the patterns and practices that will help you turn the scary big ball of mud into a tested code base.

I’m excited to have Phil back.  I’ve heard him speak many times and have always found his talks both informative and entertaining.

This month we’re meeting in the 2nd floor conference room at 900 E. 96th Street.  Registration begins at 5:30 and the main event kicks off at 6:00.  Snacks and soft drinks will be provided.

I hope to see you there!