Give The Iron

Correlation is not causation

But it will help you find the cause. Correlation Id](https://www.rapid7.com/blog/post/2016/12/23/the-value-of-correlation-ids/) is a value that can for instance be used to track calls in log files as it moves between services. It's a common practice when architecting a system as Microservices, but it's a useful practice in any system that involves calls between services and APIs, since it allows an fairly easy way to group log messages from different logs. It also helps when dealing with systems that span time zones and organizations since the correlation id can be easily passed along in support messages.

Now that sounds so good I gotta get me some of that.

For ASP.NET Core it's easy peasy using the Correlation Id library, but for old ASP.NET 4 I haven't found an out of the box solution so I decided to roll my own. The goal is for all log calls to display the correlation id, and to add correlation id to the headers of any calls using HttpClient.

Imitation is the sincerest form of flattery

Writing a custom layout renderer for NLog took some time for reasons I'll get into in a later post (promises, promises), but I got it in place and it works. I took inspiration from the Correlation Id library and use a ICorrelationIdAccessor to be able to inject the correlation id into service classes.

public interface ICorrelationIdAccessor
{
    string CorrelationId { get; }
}

public class CorrelationIdAccessor : ICorrelationIdAccessor
{
    private static AsyncLocal<string> _correlationId = new AsyncLocal<string>();

    public string CorrelationId
    {
        get => _correlationId .Value;
        set => _correlationId .Value = value;
    }
}

The above will let you set the CorrelationId at the beginning of a call to a Web API or any other ASP.NET call and be able to access it from anywhere during that call. So why don't we do just that.

ASP.NET Web API 2

If you're using ASP.NET Web API 2 you can easily create a middleware and set the CorrelationId that way. This will check if the header has a correlationId set and if not generate a new one so we can still enjoy that sweet correlation in our log files.

        var correlationId = request.Headers.Get("x-correlation-id");

        // If the correlationId is not set on the header, generate a new GUID and use that instead.
        if (string.IsNullOrWhatespace(correlationId))
            correlationId = Guid.NewGuid().ToString();

After that it grabs the CorrelationIdAccessor and sets the CorrelationId.

        var scope = request.GetDependencyScope();
        var accessor = scope.GetService<CorrelationContextAccessor>();
        accessor.CorrelationId = correlationId;

The full handler looks like

public class CorrelationIdHandler : DelegatingHandler
{
    protected override Task<HttpResponseMessage> SendAsync(HttpRequestMessage request, CancellationToken)
    {
        // See if there's a CorrelationId on the request header
        // I actually store the header name in a const string, but for brevity it's a magic string here
        var correlationId = request.Headers.Get("x-correlation-id");

        // If the correlationId is not set on the header, generate a new GUID and use that instead.
        if (string.IsNullOrWhatespace(correlationId))
            correlationId = Guid.NewGuid().ToString();

        // You can do var accessor = new CorrelationIdAccessor();
        // but since I've got Dependency Injection setup I can grab it from IDependencyScope
        var scope = request.GetDependencyScope();
        var accessor = scope.GetService<CorrelationIdAccessor>();
        accessor.CorrelationId = correlationId;
    }
}

ASP.NET WCF and friends

But what about if you're not using Web API 2? Well you can always go straight to Global.asax.cs and Application_BeginRequest

public class Global : System.Web.HttpApplication
{
    protected void Application_BeginRequest(object sender, EventArgs e)
    {
        // See if there's a CorrelationId on the request header. Here I'll use HttpContext.Current to get the request header
        var correlationId = HttpContext.Current.Request.Headers.Get("x-correlation-id");

        // If the correlationId is not set on the header, generate a new GUID and use that instead.
        if (string.IsNullOrWhatespace(correlationId))
            correlationId = Guid.NewGuid().ToString();

        // If you're using a Dependency Container framework you can probably get the CorrelationIdAccessor that way
        // If not you can still use new
        var accessor = new CorrelationIdAccessor();
        accessor.CorrelationId = correlationId;
    }
}

It's pretty similar to the middleware implementation, but here I use new on the ContextIdAccessor since I actually haven't test if I can use GetDependencyScope() in this instance... :)

It's correlation time

After that you can either new up a CorrelationIdAccessor or inject a ICorrelationIdAccessor into your classes and for that specific call you will get the same CorrelationId everywhere.

What sorcery is that?!?

Now if you looked at the CorrelationIdAccessor, or in my case looked at the source code for the CorrelationContextAccessor, and thought "what's that voodoo happening using AsyncLocal?!? Well I'll get into that in my next post. Hopefully it won't take another two years for me to get around to that... :)

I've been a WinMerge user for years. Despite that work on the 2.x branch seemed to stop after the 2.14.0 release in 2013, I kept using it since it did all the things I needed it to do. However, there were a few annoying issues with certain compare scenarioshowever, so when all of sudden version 2.16.0 showed up, it was a welcome site.

The 2.16.0 version brought with it several new features, but I quickly noticed Visual Studio no longer opened it correctly when wanted to compare files. It turned out the addition of the 3-way compare/merge had changed the command line parameters. Reading up on WinMerge's Command Line interface and what Visual Studio can pass into a third party compare/merge tool, I got it working again.

Using the 32-bit version WinMergeU.exe is found

C:\Program Files (x86)\WinMerge\WinMergeU.exe

For Compare the Arguments should be

/e /u /wl /wr /dl %6 /dr %7 %1 %2

and for Merge they should be

/e /u /wl /dl %6 /dr %7 %1 %2 /o %4

Setting up External Tools for Compare and Merge in Visual Studio

So if the above looks great, but you have no idea on how to set it up, just open Visual Studio, click the Tools menu and select Options

Then under Source Control, select Visual Studio Team Foundation Server and click Configure User Tools...

After that you can click Add and configure Compare and Merge described above.

Just about every service class used in our ASP.NET Classic sites need a logger. The Nlog way to do that is to put this in your class

    NLog.LogManager.GetCurrentClassLogger();

But after setting up logging in ASP.NET Core I really wanted some ILogger Dependency Injecting magic. With Dependency Injecting being a fundamental part of ASP.NET Core, setting up an ILogger is done by Injecting the logger into the constructor

public class WorkingClass
{
    private readonly ILogger _logger;
    public WorkingClass(ILogger<WorkingClass> logger)
    {
        _logger = logger;
    }

Injecting the logger not only makes the code cleaner, it's also far easier to test. So how do I get me a piece of that action?

StructureMap to the rescue

Note that we use StructureMap as our Dependency Injection Framework, but I'm sure the following has similar ways in your favorite Dependency Injecting framework. Anyhoo, to setup the Injection we use the StructureMap Registry

public class DomainRegistry : Registry
{
    public DomainRegistry()
    {
        Scan(
            scan => {
                scan.TheCallingAssembly();
                scan.WithDefaultConventions();
            });
				
        For<ILogger>().AlwaysUnique().Use(c => GetLogger(c));
    }
    private ILogger GetLogger(IContext context)
    {
        return NLog.LogManager.GetLogger(
            context.ParentType?.FullName ?? "Datema.EasyShop");
    }
}

So lets break it down. First line of interest

For<ILogger>().AlwaysUnique().Use(c => GetLogger(c));

Since the Logger is unique per class AlwaysUnique() is added after the For<ILogger>(), which will make sure the call to Use(...) gets called for each object that want's a logger. The last part is Use(c => GetLogger(c)); which is required since it's not allowed to have a null propagating operator in a lambda expression. Why use one of those? Lets find out!

return NLog.LogManager.GetLogger(
    context.ParentType?.FullName ?? "Datema.EasyShop");

The interesting bit here is what's passed into the GetLogger call. The StructureMap IContext we get from the Use(c => GetLogger(c)); call knows which type it's creating the ILogger for, and it's type is stored in context.ParentType. That means we can use the ParentType.FullName to create a new Logger with the full name of the class being created. That's exactly what we want to achieve, so why the whole "?." or null propagating operator? The DomainRegistry will eventually be inserted into a StructureMap Container, and on startup of the application, there's a call to container.AssertConfigurationIsValid(); to make sure it has everything it needs. The call to AssertConfigurationIsValid() works by attempting to create every object the IContainer is tracking. This means it will attempt to create a ILogger directly, without a value set in context.ParentType since there is none. With more complex DI scenarios it's easy to miss something, and failing on startup is better than later on when some specific part of the system is accessed.

In a new attempt to reboot my blogging I'm putting my exploratory coding sessions in writing (although I'm not sure I can call it reboot, since I'm not sure I booted my blogging to begin with). With exploratory coding I mean that when I come across a question I have, instead of immediately searching for the answer, I try and explore it with code instead. I use LINQPad since it's so fast to get up and running. So over to the question.

Question: Static fields are shared in all instances of a class, but what happens if the class is a generic class?

The specific problem I had was I'm storing a token in a static string, but I didn't want the token to be shared between different concrete types. So, in the following code, would the StaticString be shared between GenericClass<int> and GenericClass<string>?

void Main()
{
    GenericClass<int>.StaticString = "genericInt";
    GenericClass<string>.StaticString = "genericString";
    GenericClass<int>.StaticString.Dump();
    GenericClass<string>.StaticString.Dump();
}

public class GenericClass<T>
{
    public static string StaticString { get; set; }
}

The result is good for me for the problem I have

I'm a GenericClass<int> StaticString
I'm a GenericClass<string> StaticString

As you can see by the result, they aren't shared. Now I remember from way back I read that Generics in the Run Time work differently with value types and reference types (https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/generics/generics-in-the-run-time) so to be sure I test with another reference type as well.

    ...
    GenericClass<Exception>.StaticString = "I'm a GenericClass<Exception> StaticString";
    GenericClass<Exception>.StaticString.Dump();

And the result is more of the same

I'm a GenericClass<int> StaticString
I'm a GenericClass<string> StaticString
I'm a GenericClass<Exception> StaticString

I could have added unit tests to verify this, but it seems unnecessary to have unit tests covering the C# language. I just needed to check how the language behaves for generics.