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 });

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.

A Dictionaryis used to do quick* lookups of a value using a specific key. Any type can be used as both value and key but if you use your own custom type as a key you need to think of a few things.

*Quicker then say a LINQ-query on a list like MyList.Where(x => x.id == id).Single();

Default GetHashCode() and Equals() are equal if referencing the exact same object

For the following to make sense you need to understand the difference between same object and equal object. The same object is a reference to the exact same object in memory, whereas different objects in memory are only considered equal if you the programmer defines them as such:

Person A = new Person()
{
    FirstName = "Gypsy",
    LastName = "Danger"
};
 
Person B = new Person()
{
    FirstName = "Gypsy",
    LastName = "Danger"
};
 
Person C = B;
 
if (B.Equals(C)) // true
    Console.WriteLine("These references are the same");
 
if (A.Equals(B)) // not true unless Person implements Equals()
    Console.WriteLine("These references are equal");

public Person Class
{
    public string FirstName { get; set; }
    public string LastName { get; set; }
 
    public override bool Equals(object other)
    {
        if (other == null || !(other is Person))
            return false;
 
        return Equals(other as Person);
    }
 
    public bool Equals(Person other)
    {
        return FirstName.Equals(other.FirstName, StringComparison.Ordinal) &&
               LastName.Equals(other.LastName, StringComparison.Ordinal);
    }
 
    // I found the following pattern on StackOverflow. The numbers are
    // prime numbers which magically (or mathematically if you believe
    // in that stuff) creates a fairly good normal distribution of the
    // numbers, which is good for hashing (apparently).
    public override GetHashCode()
    {
        int hash = 17;
        hash = hash * 23 + FirstName.GetHashCode();
        hash = hash * 23 + LastName.GetHashCode();
        return hash;
    }
}

class PersonComparer : IEqualityComparer
{
    public bool Equals(Person A, Person B)
    {
        if (A.FirstName.Equals("Connor" StringComparison.Ordinal) &&
            A.LastName.Equals("MacLeod, StringComparison.Ordinal))
            return false; // There can be only one
 
        return A.Equals(B);
    }
}

var newMap = new Dictionary();
foreach (var entity in entityMap)
{
    newMap.Add(entity.Key, entity.Value);
}
entityMap = newMap;