Give The Iron

My desk is a mess. There's papers, stickers, spare parts, glasses cleaning cloths, at least one coffee cup, tiny plush toys, and lots of knick knacks and other crap. It is my mess and I know where everything is so it's not a problem... until my wife needs to get something off the desk.

Luckily it's a rare thing that she needs to get something off my desk, and I can usually guide her to whatever she's after. So what all of this have to do with coding and Roslyn Analyzers? Unlike my desk, which is almost only accessed by me, the code I write is almost always read by others. It starts with a code review, but will continue for years as others maintain and add features to the code. So, unlike my mess on the desk, messy code is the entire teams problem.

Identify messy code

Messy code is any code that doesn't follow your coding style. However, without tooling to help, a coding style is just another document that very few will read. Luckily in .NET (or dotnet if you are in the #dropthedot crowd...) there are tools built right into the compiler, the .NET Compiler Platform (Roslyn) Analyzers, or Roslyn Analyzers for short.

What can the Roslyn Analyzers help us with?

The Roslyn Analyzers analyze two aspects of your code, Code Style and Code Quality.

Code Style rules

Code Style rules help with maintaining a coding style throughout code and are grouped into 5 categories and are named IDExxxx.

• Language
  Defines how the code is written using the language features, such as using parenthesis for clarification or prepending local calls with this..

• Unnecessary code
  Detects code that can be simplified or code that is not in use. Since this is a compile time analysis, code called using reflection and magic strings are likely not detected.

• Miscellaneous
  This contains some rules around wrong or old usage of SuppressMessageAttribute.

• Formatting
  Contains one rule IDE0055, which is all the things formatting. It validates configuration around new lines, indentation, spacing and how using directives are sorted.

• Naming
  Contains one rule IDE1006 with a very customizable configuration for how fields, properties, classes etc are named. Should local fields be prepended with _, should methods use cameCase or PascalCase and lots more.

Code Quality Rules

Code Quality rules are there to help writing better and safer code by warning when the code isn't using the .NET APIs as expected, or when the code references unsafe methods and more. These rules are grouped into 11 categories and are mostly named CAxxxx.

• Design
  Helps with following the .NET Framework Design Guidelines with rules to ensure the code validates arguments in public methods, enums have zero values, classes are declared in a namespace and lots more.

• Documentation
  In .NET 7 there's only one rule CA1200 which validates that cref in XML-documentation doesn't include prefixes.

• Globalization
  Helps with code that is affected by the current culture or that is used to localize the application.

• Portability and interoperability
  Validates rules when interacting with COM clients.

• Maintainability
  Rules to help write more maintainable code, such as not using large dependency trees and using nameof() instead of magic strings.

• Naming
  Warns if names violating the .NET naming guidelines for example enums with Flag attribute should be pluralized and identifiers should not differ only by case.

• Performance
  Contains a bunch of rules to help writing more performant code, for instance using Length or Count properties instead of Linq's Count() method.

• SingleFile
  These rules have the name IL3000 to IL3003 and help with issues related to publishing as single file, like avoid the property Assembly.Location since it returnsstring.Empty when publishing as single file.

• Reliability
  Helps with writing code that use threads and memory correctly, for example disposing objects that implement IDisposable.

• Security
  Provide assistance to discover SQL Injection, using unsafe encryption algorithms, using antiforgery tokens in ASP.NET Core MVC Controllers, and lots more.

• Usage
  These rules helps with writing code that could cause unexpected behavior or that are likely to cause issues. For example warn when calling virtual methods inside a constructor, or passing a URI as a string when there is a overload that accepts [codespan lang="csharp"]Uri[/codespan.].

How to enable the Roslyn Analyzers

So how do we enable the Roslyn Analyzers? Short answer, if you are targeting net5.0 or above they are already enabled, but only a small set of rules. If you are targeting a version earlier than net5.0, for instance net472, the analyzers can be enabled in the project file, as long as you are using a SDK-style project file.

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <TargetFramework>net472</TargetFramework>
    <EnableNETAnalyzers>true</EnableNETAnalyzers>
  </PropertyGroup>

</Project>

If you're not using an SDK-style project file, you can use a NuGet package Microsoft.CodeAnalysis.NetAnalyzers.

Configure the Roslyn Analyzers

In .NET 7 20 rules out of several hundreds are enabled by default. The reason why there are so few rules enabled by default is that enabling more rules would possibly break a lot of builds out there that treat warnings as errors.

<TreatWarningsAsErrors>true</TreatWarningsAsErrors>

To enable more rules there's two main paths, enabling more rules in the project file or adding rule severity in the .editorconfig.

Configuration in the project file

To configure which rules are analysed, add the element AnalysisLevel to the project file.

  <PropertyGroup>
    <AnalysisLevel>latest-all</AnalysisLevel>
  </PropertyGroup>

The value for <AnalysisLevel> is made up of two parts, the version and the mode: <version>-<mode>. For instance the above will analyze all rules based on the latest version of the .NET SDK.

Version

The version specifies which rules to analyze based on the .NET version specified. Uses can be latest or the current version, preview any preview that might be installed, or any specific version such as 5.0 or 7.

Mode

Mode sets the amount of rules to analyze. The amount of rules include in order of increased amount of rules from none (disable all), default, minimum, recommended to all. It's a rather rough way of determining which rules that are used, but it will get you started.

I recently put together a small message queueing system for work. The purpose was to just be able to do some work asynchronously to not block the current call. I didn't feel the need was there for an actual messaging system like MassTransit so I rolled my own. Perhaps that will be a post in the future, but this one mostly is focused on how to call a generic method from a non-generic method passing in a instance of a sub class cast to a base class using reflection.

Skip directly to the short version.

Short version long

It starts with enqueueing a message. The Enqueue method accepts any instance that inherits from a base class Message.

public class Message
{
    public string id { get; set; }

    // All the props
}

When enqueueing the message is serialized and stored in a database using a Dto.

public class MessageDto
{
    public string id { get; set; }
    public string TypeName { get; set; }
    public string SerializedBody { get; set; }
}

When it's time to read and act on the messages the SerializedBody needs to be deserialized to the type using name stored in TypeName. After that it's time for one or many subscribers to act on the message. A subscriber in this system is just a type inheriting from

public interface IMessageHandler<TMessage>
    where TMessage : Message
{
    Task<Result> HandleAsync<TMessage>(TMessage message);
}

To act on messages the service reads all messages from storage into a List>MessageDto>, and deserialized each message using Json.NET.

List<Message> messages = new();
foreach (var messageDto in dtos)
{
    var messageType = Type.GetType(messageDto.TypeName);
    if (JsonConvert.DeserializeObject(messageDto.SerializedBody, messageType) is Message message)
    {
        messages.Add(message);
    }
    else
    {
        // Error handling when not able to cast goes here.
    }
}

The List<Message> messages contains instances of types that inherit from Message. To get these to a subscriber they could be passed straight to the HandleAsync-method and each handler could manually cast the message to it's expected type, but that's not much fun. Also each handler needs to verify and decide what to do if the type is not the expected type. So to simplify the handlers logic the goal was instead to call the generic method HandleAsync<TMessage>(TMessage message);. Time for some reflection fun.

Reflecting of a generic nature

A subscriber is any class that implements the IMessageHandler<TMesssage> interface for a specific message. Calling a subscribers HandleAync method is easy peasy form a generic method.

// Declared with the other fields in the class
private List<Message> _handlers = new List<Message>();

// ...

public async Task ProcessMessageAsync<TMessage>(TMessage message)
    where TMessage : Message
{
    // Select will attempt to cast the handlers from type IMessageHandler to IMessageHandler<TMessage>.
    // Any class that can't be cast is returned as null so  the .Where gets rid of those.
    var handlers = _handlers.Select(handler => handler as IMessageHandler<TActivity>).Where(x => x != null);
    foreach (var handler in handlers)
    {
        // If the order of handlers is not important these calls could be added to a List<Task> and awaited
        // using Task.WhenAll(allTasks).
        await handler.HandleAsync(message);
    }
}

To call the generic ProcessMessageAsync method from a non-generic method involves three steps (and any extra validation you might want to add).

Three step program

I arrived at the following solution to get from a list containing the base class Message to the subscribers by calling the generic ProcessMessageAsync<TMessage> using some reflection.

private Task CallGenericProcessMessageAsync(Message message)
{
    var method = GetType().GetMethod(nameof(ProcessMessageAsync), BindingFlags.NonPublic | BindingFlags.Instance);
    var genericMethod = method.MakeGenericMethod(message.GetType());
    var task = (Task)genericMethod.Invoke(this, new object[] { message });
    return task;
}

First

First step is to get the MethodInfo of the method. This is done by calling GetMethod on the Type instance of the object that implements the method. In this case it's the current class so a call to GetType() does the trick.

var method = GetType().GetMethod(nameof(ProcessMessageAsync), BindingFlags.NonPublic | BindingFlags.Instance);

Second

Second step is to get the MethodInfo for the generic version by calling MakeGenericMethod passing in the Types of the generic parameters. In this case it's the Type of the message.

var genericMethod = method.MakeGenericMethod(message.GetType());

Third

Last step is to call Invoke on the method, passing in the caller (this), the method arguments as an array of objects, in this case the message.

var task = (Task)genericMethod.Invoke(this, new object[] { message });

Occasionally I have to dig through process dumps to find some nasty difficult to sort out bug. In the past I used the Task manager and right click to create a dump file

which works fine, but sometimes that turns into several process dumps over time and from different processes at the same time. This repetitive work takes minutes of my day, so why not spend hours finding an automated solution!

Enter dotnet-dump

Using dotnet-dump it's easy peasy to create dump files from .NET Core 3.x and .NET 5+, and it's the same tool for whatever platform you're on.

Installing

You need to have have .NET whatever version SDK installed to install the tool, so if you haven't done that yet go download and install. Once that is in place you can install dotnet-dump. It's installed as a global command line tool by running the following in command line

dotnet tool install --global dotnet-dump

Dumping

After that you can create a dump of a process by running

dotnet-dump collect --process-id 123

That seems easy enough it wasn't for the process id. The dotnet-dump comes with a ps command for that:

PS C:\Windows\system32> dotnet-dump ps
       972 dotnet     C:\Program Files\dotnet\dotnet.exe
      1856 dotnet     C:\Program Files\dotnet\dotnet.exe
      3044 dotnet     C:\Program Files\dotnet\dotnet.exe
      3264 dotnet     C:\Program Files\dotnet\dotnet.exe
      3384 w3wp       C:\Windows\SysWOW64\inetsrv\w3wp.exe
      5440 w3wp       C:\Windows\SysWOW64\inetsrv\w3wp.exe
      5592 w3wp       C:\Windows\SysWOW64\inetsrv\w3wp.exe
      6088 w3wp       C:\Windows\SysWOW64\inetsrv\w3wp.exe
      9628 w3wp       c:\windows\system32\inetsrv\w3wp.exe

Which is good for listing what processes the tool supports, but I need a bit more information. The processes I'm dumping are on a server with several different ASP.NET Core applications running and as you can see there's four different dotnet-processes runnning (the w3wp are IIS worker processes and I don't need those).

The Search for a one-liner PowerShell call

Getting the process the PowerShell way

To get more information about a process I can use PowerShell's Get-Process

PS C:\Windows\system32> Get-Process

Handles  NPM(K)    PM(K)      WS(K)     CPU(s)     Id  SI ProcessName
-------  ------    -----      -----     ------     --  -- -----------
   3382     139    55652     114568   1 011,17   2084   0 ccSvcHst
    538      32   209860     200304   1 156,50   2116   0 ccSvcHst
    481      36     7160       5136       1,50   4072   2 ccSvcHst
    475      35     6664       5708       0,30   8800   7 ccSvcHst
    484      36     6852       3948       0,52  10152   6 ccSvcHst
     88       7     5260       9380       0,03   1408   0 conhost

That returns every process so it's quite a lengthy list, but as a start Get-Process can filter by name

PS C:\Windows\system32> Get-Process -Name dotnet

Handles  NPM(K)    PM(K)      WS(K)     CPU(s)     Id  SI ProcessName
-------  ------    -----      -----     ------     --  -- -----------
    626     135   100312     139240      34,88    972   0 dotnet
    606     137   100612     140280      37,98   1856   0 dotnet
    558      91    66268     100420      11,33   3044   0 dotnet
    546      91    69588     104200      10,42   3264   0 dotnet
    737     102   106256     140772      12,58   6800   0 dotnet

That's better, but it's still missing the application pool information. Luckily for me the application pools are run under the default user names so if I also add to output the name I can see those

PS C:\Windows\system32> Get-Process -Name dotnet -IncludeUserName

Handles      WS(K)   CPU(s)     Id UserName               ProcessName
-------      -----   ------     -- --------               -----------
    632     139224    34,89    972 IIS APPPOOL\Datema ... dotnet
    620     140312    38,06   1856 IIS APPPOOL\Datema ESC dotnet
    555     100436    11,39   3044 IIS APPPOOL\Datema ... dotnet
    538     104144    10,53   3264 IIS APPPOOL\Datema ESC dotnet
    740     140760    12,58   6800 IIS APPPOOL\Datema ... dotnet

There they are, but some of the longer ones are cropped "IIS APPPOOL\Datema ...". Well there's some more PowerShell magic that can format the returned table

PS C:\Windows\system32> Get-Process -Name dotnet -IncludeUserName | Format-Table -Wrap -AutoSize

Handles  WS(K) CPU(s)    Id UserName                      ProcessName
-------  ----- ------    -- --------                      -----------
    424  77572   2,58  3268 IIS APPPOOL\Datema ESC        dotnet
    595 123852  12,42  3572 IIS APPPOOL\Datema ES License dotnet
    460  72296   2,09  3820 IIS APPPOOL\Datema ESC 2.0    dotnet
    659 127604   8,69 10432 IIS APPPOOL\Datema ESC        dotnet

First of all the | character is called a pipe character. It takes the result of the previous command (Get-Process) and moves it into the next command (Format-Table). PowerShell is a object based language so it's actually passing an object that contains rows and properties and those properties can be accessed individually, which we use when it's time to filter the output. To filter the output from Get-Process we can pipe it to Where-object

PS C:\Windows\system32> Get-Process -Name dotnet -IncludeUserName | Where-Object UserName -like 'IIS APPPOOL\Datema ESC 2.0' | Format-Table -Wrap -AutoSize

Handles  WS(K) CPU(s)   Id UserName                   ProcessName
-------  ----- ------   -- --------                   -----------
    662 128160   8,77 7540 IIS APPPOOL\Datema ESC 2.0 dotnet

So connecting that to dotnet-dump required a lot of trial and error but this is the result

PS C:\Windows\system32> Get-Process -Name dotnet -IncludeUserName | Where-Object UserName -like 'IIS APPPOOL\Datema ESC' | ForEach { & "dotnet-dump" @("collect", "--process-id", $_.Id) }

Writing full to C:\Windows\system32\dump_20210520_121145.dmp
Complete

Writing full to C:\Windows\system32\dump_20210520_121154.dmp
Complete

Notice I'm actually calling this for the application pool DATEMA ESC since I wanted to see that it actually worked for more than one result. Anyways to parse what's happening there at the end. The ForEach can take a script block which will be executed for each result in the previous call. Inside that script block is the call operator & which calls a command. I use it since dotnet-dump as far as I know isn't a PowerShell command and can't handle objects piped into it. The call operator first takes an optional path, the command or application, and last the arguments. I excluded the path, the command is "dotnet-dump", and the arguments is an array of strings which can be created in PowerShell with the @ character.

Since this achieved my goal I stopped there, but the above could be re-written as a script or possibly made into an alias, I really don't know. Here ends my PowerShell knowledge :)

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.