1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

The Curious Case of the Null StringBuilder


Today was spent tracking down a very weird bug. In production we were seeing an important part of our document reading fail. We kept getting NullReferenceExceptions when calling AppendLine on a non-null StringBuilder. It didn't prevent us reading the document however the result would be significantly different to the same document on a local instance of our program.

It only started occurring after the production server had been running for a few days which meant we couldn't debug it locally. We were running .NET 4.5.2.

Luckily we had lots of logging to track down the issue. The problem was in a class like this:

public class AlgorithmLogicLogger
    private readonly StringBuilder stringBuilder;

    public AlgorithmLogicLogger()
        stringBuilder = new StringBuilder();

    public void Append(string s)
        var message = BuildStringDetails(s);


    private static string BuildStringDetails(string s)
        return $"{DateTime.UtcNow}: {s}";

This was a class which was originally intended to provide detailed logging for a complicated algorithm.

The call to StringBuilder.AppendLine() inside Append was throwing a NullReferenceException.

After ensuring no weird reflection was taking place and using Ildasm to inspect the compiled code we were sure it wasn't possible for stringBuilder to be null. It was always instantiated in the constructor and never changed elsewhere.

The next working theory was that a multi-threading issue was somehow calling Append prior to the field being set. This was also discounted both because it wouldn't have been possible and also because the code in question was not called from multiple threads.

After ensuring that it wasn't the case that the garbage collector wasn't somehow incorrectly collecting the string builder (because it was only written to, never read, the reading hadn't been implemented yet) we were beginning to run out of ideas.


ASP.NET Core Identity Using PostgreSQL


Following on from my much older posts about using ASP.NET Identity 2 to manage user accounts in MVC 4 sites, today I needed to use Identity on an ASP.NET Core MVC site.

As with previous versions, the current Identity library for .NET Core 1.1 uses Entity Framework out-the-box. Luckily it's much easier to change this behaviour for the simplest register/log-in flow.


Firstly you need to get the right NuGet package. For the Identity library without Entity Framework this is:


Once this is installed in your project you need to provide your own implementation of the IUserStore<TUser> and IRoleStore<TRole>.

Unlike previous versions the TUser no longer needs to implement a specific interface.

For my project I was using PostgreSQL as the database and Dapper.Contrib as the ORM. My User class was simply:

public class User
    public Guid Id { get; set; }

    public string UserName { get; set; }

    public string NormalizedUserName { get; set; }

    public string Email { get; set; }

    public string PasswordHash { get; set; }

(I had to do some faffing around to make sure the table name was detected correctly in my schema but could have called the table anything, it doesn't have to be called "user").


White Automation


I've spent a few days getting very in-depth with White for WPF UI automation so in order to store the information while it's still fresh in my mind I am writing a blog post.

White is a framework for automating interactions with desktop Windows applications. It is built on top of the UIAutomation library which is part of the .NET framework. The project is currently not very active on GitHub but despite this it's still very good at dealing with desktop interactions on Windows.

Automate all the things

For this tutorial I've decided to automate interactions with the Visual Studio 2015 application; since it's software that most people interested in following this tutorial will probably have.

I'm creating my application as a .NET 4.6.1 console application. Generally White is used for automated UI tests, so you might be using a test project. Whichever project type you choose the information in this tutorial will still be relevant.

First we need to add the TestStack.White NuGet package. Right click your project and select Manage NuGet Packages:

add TestStack.White as a NuGet package

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18