It turns out that we absolutely can! In this article, I’ll touch on one of the Microsoft Learn articles as well as explain an alternative approach… That you can run right in your browser with dotnetfiddle!

Microsoft Learn Article on IServiceCollection in Console Applications

Microsoft Learn is a tremendous source of valuable information. I feel like in recent years it continues to surprise me how much valuable information we can find there since I’m used to just relying on MSDN for doc comments and maybe the odd helpful example.

However, in this case, I was a little taken back because the article seemed to be a little bit more cumbersome than I was expecting. If our goal is just to be able to use the IServiceCollection interface so that we can work with our familiar dependency injection API, I would hope that we can stick to the basics.

However, it looks like the example in the tutorial goes a little bit beyond that and demonstrates the usage of an HostApplicationBuilder.

HostApplicationBuilder For Dependency Injection

Let’s look at the example code, which is taken directly from the Microsoft Learn article:

using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;
using ConsoleDI.Example;

HostApplicationBuilder builder = Host.CreateApplicationBuilder(args);

builder.Services.AddTransient<IExampleTransientService, ExampleTransientService>();
builder.Services.AddScoped<IExampleScopedService, ExampleScopedService>();
builder.Services.AddSingleton<IExampleSingletonService, ExampleSingletonService>();
builder.Services.AddTransient<ServiceLifetimeReporter>();

using IHost host = builder.Build();

ExemplifyServiceLifetime(host.Services, "Lifetime 1");
ExemplifyServiceLifetime(host.Services, "Lifetime 2");

await host.RunAsync();

static void ExemplifyServiceLifetime(IServiceProvider hostProvider, string lifetime)
{
    using IServiceScope serviceScope = hostProvider.CreateScope();
    IServiceProvider provider = serviceScope.ServiceProvider;
    ServiceLifetimeReporter logger = provider.GetRequiredService<ServiceLifetimeReporter>();
    logger.ReportServiceLifetimeDetails(
        $"{lifetime}: Call 1 to provider.GetRequiredService<ServiceLifetimeReporter>()");

    Console.WriteLine("...");

    logger = provider.GetRequiredService<ServiceLifetimeReporter>();
    logger.ReportServiceLifetimeDetails(
        $"{lifetime}: Call 2 to provider.GetRequiredService<ServiceLifetimeReporter>()");

    Console.WriteLine();
}

There’s a lot going on here, of course, because they want to use a single example to demonstrate a few different things. However, my biggest challenges with this is that we can see the IServiceCollection being used via the builder.Services property call… but why do we need to go make an entire hosted application here?

Now, I’m not claiming that you shouldn’t use a hosted application or anything like that — but I am saying that this feels a little bit heavy-handed. If I just want to use IServiceCollection then why am I required to build a hosted application?

Using IServiceCollection in Console Applications Directly

It turns out that it’s not complex rocket surgery to get this to work without the hosted application pieces from the Microsoft Learn example. That’s important for me because I want to provide people alternatives when I create content about Autofac and they just want to use IServiceCollection like they are familiar with.

Let’s look at this example code which you can see directly on dotnetfiddle:

Simply, we can create a new service collection by creating a new ServiceCollection instance:

var services = new ServiceCollection();

Interestingly there was no dependency on having a hosted application or any other type of builder to do this. We can leverage it directly. It’s also important to note in the dotnetfiddle example that I shared that there are no Nugets imported. So we are able to create this instance without additional packages added.

From there, we can start to register our dependencies directly onto the IServiceCollection (keeping in mind I am only illustrating one type of dependency here):

services.AddSingleton<MyService>();
services.AddSingleton<MyDependency>();

However, this is just the service collection and we still need to create the instance of a service provider that we can resolve dependencies from:

using var serviceProvider = services.BuildServiceProvider();

With the service provider available, we can go ahead and resolve dependencies directly from it:

var myService = serviceProvider.GetRequiredService<MyService>();

Wrapping Up IServiceCollection in Console Applications

To wrap up this article, we don’t need to go with a hosted application if we want to leverage an IServiceCollection in console applications for dependency injection. While the Microsoft Learn article is awesome with plenty of solid examples, I felt like it overcomplicated what could otherwise be a bit more straightforward.

So if you’re looking to go leverage an IServiceCollection in your console projects instead of Autofac, go nuts! Even though I like using Autofac for all of my dependency injection, I think it’s important to understand the options that you have!

If you found this useful and you’re looking for more learning opportunities, consider subscribing to my free weekly software engineering newsletter and check out my free videos on YouTube! Meet other like-minded software engineers and join my Discord community!

Want More Dev Leader Content?

• Follow along on this platform if you haven’t already!

• Subscribe to my free weekly software engineering and dotnet-focused newsletter. I include exclusive articles and early access to videos:
  SUBSCRIBE FOR FREE

• Looking for courses? Check out my offerings:
  VIEW COURSES

• E-Books & other resources:
  VIEW RESOURCES

• Watch hundreds of full-length videos on my YouTube channel:
  VISIT CHANNEL

• Visit my website for hundreds of articles on various software engineering topics (including code snippets):
  VISIT WEBSITE

• Check out the repository with many code examples from my articles and videos on GitHub:
  VIEW REPOSITORY

This will be part of a series where I explore dependency resolution with Autofac inside of ASP.NET Core. I'll be sure to include the series below as the issues are published:

• Part 1: AutofacServiceProviderFactory in ASP.NET Core - Problems With Dependency Injection

• Part 2: Autofac ContainerBuilder In ASP.NET Core – What You Need To Know

• Part 3: Autofac ComponentRegistryBuilder in ASP.NET Core - How To Register Dependencies

At the end of this series, you'll be able to more confidently explore plugin architectures inside of ASP.NET Core and Blazor -- which will be even more content for you to explore. Keep your eyes peeled on my Dometrain courses for a more guided approach to these topics later in 2023.

Where Did We Leave Off With Autofac in ASP.NET Core?

The previous two articles looked at the following scenarios:

• Setting up using the AutofacServiceProviderFactory as the standard recommended approach

• Skipping AutofacServiceProviderFactory and using Autofac ContainerBuilder directly

In both cases, we were able to get a web application up and running using Autofac for dependency injection. However, both of these had limitations around:

• Accessing the WebApplication instance on the container

• Weird nuances with minimal API support

While both options are absolutely viable — and may be great for you given your constraints — I wanted to push a bit further to see if the wrinkles could be ironed out. I want to strive towards having configuration done in separate Autofac modules and pushing towards a C# plugin architecture for the majority of my application development.

Exploring A Sample ASP.NET Core Application

This one is going to be different than the previous articles — we’ve achieved plugin status. I want to show you how the code from the previous examples can now be broken out into more dedicated pieces. Most of what we’ve gone over before is the same concept, but I’ve reduced the weather route to something more contrived just to eliminate the waste.

Make sure to follow along with this video on Autofac for additional explanations as we go through:

The Entry Point Configuration

Here’s how simple our Program.cs file is now:

await new FullResolveWebApi().RunAsync(CancellationToken.None);

That’s right — one line of code. But okay, you’re probably curious where all the setup actually takes place. Let’s go a bit deeper:

using Autofac;

internal sealed class FullResolveWebApi
{
    public async Task RunAsync(CancellationToken cancellationToken)
    {
        var containerBuilder = new MyContainerBuilder();
        using var container = containerBuilder.Build();
        using var scope = container.BeginLifetimeScope();

        var app = scope
            .Resolve<ConfiguredWebApplication>()
            .WebApplication;
        await app.RunAsync(cancellationToken).ConfigureAwait(false);
    }
}

This looks familiar to what we saw in the previous example! We’re able to get the goodness of that really lean startup configuration But wait! What’s that custom MyContainerBuilder class?!

using Autofac;

using System.Reflection;

internal sealed class MyContainerBuilder
{
    public IContainer Build()
    {
        ContainerBuilder containerBuilder = new();

        // TODO: do some assembly scanning if needed
        var assembly = Assembly.GetExecutingAssembly();
        containerBuilder.RegisterAssemblyModules(assembly);

        var container = containerBuilder.Build();
        return container;
    }
}

This is missing from the code above if we compare it to the previous article, but it can also be extended to do assembly scanning if that’s a requirement. So far, so good. We have one more piece though, and that’s ConfiguredWebApplication:

internal sealed class ConfiguredWebApplication(
    WebApplication _webApplication,
    IReadOnlyList<PreApplicationConfiguredMarker> _markers)
{
    public WebApplication WebApplication => _webApplication;
}

internal sealed record PreApplicationBuildMarker();

internal sealed record PreApplicationConfiguredMarker();

This marker record might seem a bit confusing but we’ll tie this all together in a dedicated section.

WebApplicationBuilder Autofac Module

Now that we’ve seen how our initial ASP NET Core application bootstrap code is looking, it’s time to look at some of the core dependency registration that’s going to be a union of what we saw in the previous articles AND some new behavior:

using Autofac;
using Autofac.Extensions.DependencyInjection;

internal sealed class WebApplicationBuilderModule : global::Autofac.Module
{
    protected override void Load(ContainerBuilder builder)
    {
        builder
            .Register(ctx =>
            {
                var builder = WebApplication.CreateBuilder(Environment.GetCommandLineArgs());
                return builder;
            })
            .SingleInstance();
        builder
            .Register(ctx =>
            {
                var config = ctx.Resolve<WebApplicationBuilder>().Configuration;
                return config;
            })
            .As<IConfiguration>()
            .SingleInstance();

        WebApplication? cachedWebApplication = null;
        builder
            .Register(ctx =>
            {
                if (cachedWebApplication is not null)
                {
                    return cachedWebApplication;
                }

                var webApplicationBuilder = ctx.Resolve<WebApplicationBuilder>();
                ctx.Resolve<IReadOnlyList<PreApplicationBuildMarker>>();

                webApplicationBuilder.Host.UseServiceProviderFactory(new AutofacServiceProviderFactory(containerBuilder =>
                {
                    foreach (var registration in ctx.ComponentRegistry.Registrations)
                    {
                        containerBuilder.ComponentRegistryBuilder.Register(registration);
                    }

                    containerBuilder
                        .RegisterInstance(webApplicationBuilder)
                        .SingleInstance();
                }));

                cachedWebApplication = webApplicationBuilder.Build();
                return cachedWebApplication;
            })
            .SingleInstance();
        builder
            .Register(ctx =>
            {
                var app = ctx.Resolve<WebApplication>();
                app.UseHttpsRedirection();
                return new PreApplicationConfiguredMarker();
            })
            .SingleInstance();
        builder
            .RegisterType<ConfiguredWebApplication>()
            .SingleInstance();
    }
}

You’ll notice that the code snippet above shows that we’re now mixing in the AutofacServiceProviderFactory alongside our standalone Autofac ContainerBuilder approach. What we’re able to do is leverage this code to re-register some of the dependency registrations on the second Autofac ContainerBuilder:

foreach (var registration in ctx.ComponentRegistry.Registrations)
{
    containerBuilder.ComponentRegistryBuilder.Register(registration);
}

Now that we can duplicate our registrations, we get the registration of the WebApplication from the parent container onto the dedicated WebApplication‘s ContainerBuilder. But two things we should note:

• We need to cache the WebApplication instance. This is because later on when the WebApplication instance itself needs to resolve dependencies that depend on an instance of WebApplication, it will go re-run the registration even though it’s a single instance! This is because this is a duplicated registration across the container that has never technically been executed at the time of registration. We may need to pay special attention to this sort of thing as we go forward to avoid expensive re-resolution of types.

• We see another marker type: PreApplicationConfiguredMarker. What’s with these markers?!

Marker Classes for Controlling Dependency Ordering and Requirements

So far we’ve seen two instances of marker types. These marker types are a way that we can force certain registration code to execute before some other registration code executes. This is a more flexible way of saying “I don’t care which types specifically get registered or which registration code runs, but anyone that needs to be registered before some checkpoint, make sure you return one of these”. This allows us to force code to execute before a checkpoint.

If we consider the code in the example above, we see that the ConfiguredWebApplication instance requires the full collection of PreApplicationConfiguredMarker instances. This means that we can’t even create an instance of ConfiguredWebApplication until all dependent code, as indicated by our marker type, has finished executing. This essentially forces Autofac to run certain code for us because it will attempt to run all code that provides one of these marker instances.

The two markers we see in this example code are very naive/primitive — however, this concept can be expanded to provide more robust checkpoints in your dependency registration process.

C# Plugin Architecture in ASP.NET Core Unlocked!

The cat’s out of the bag! We can now successfully create an Autofac module for a plugin! This code shows us enabling C# plugin architecture in ASP.NET Core as we’re able to add a new discoverable module that adds its own API endpoints:

using Autofac;

namespace Plugins;

internal sealed class PluginModule : Module
{
    protected override void Load(ContainerBuilder builder)
    {
        // load whatever dependencies you want in your plugin
        // taking note that they will be able to have access
        // to services/dependencies in the main application
        // by default
        builder.RegisterType<DependencyA>().SingleInstance();
        builder.RegisterType<DependencyB>().SingleInstance();
        builder.RegisterType<DependencyC>().SingleInstance();

        // minimal APIs can resolve dependencies from the
        // method signature itself
        builder
            .Register(ctx =>
            {
                var app = ctx.Resolve<WebApplication>();

                app.MapGet(
                    "/hello",
                    (
                        DependencyA dependencyA
                      , DependencyB dependencyB
                      , DependencyC dependencyC
                    ) =>
                    {
                        return new
                        {
                            AAA = dependencyA.ToString(),
                            BBB = dependencyB.ToString(),
                            CCC = dependencyC.ToString(),
                        };
                    });

                // this is a marker to signal a dependency
                // before the application can be considered
                // configured
                return new PreApplicationConfiguredMarker();
            })
            .SingleInstance();
    }
}

internal sealed class DependencyA(
    WebApplicationBuilder _webApplicationBuilder)
{
    public override string ToString() => _webApplicationBuilder.ToString();
}

internal sealed class DependencyB(
    Lazy<WebApplication> _webApplication)
{
    public override string ToString() => _webApplication.Value.ToString();
}

internal sealed class DependencyC(
    IConfiguration _configuration)
{
    public override string ToString() => _configuration.ToString();
}

If you’d like a more full explanation as to what you’re seeing, I highly recommend you read the articles linked at the top of this one first just to get an idea of why we have some dependencies set up like this. The TL;DR is that this code demonstrates that we can access some dependencies that are of interest to us when building plugin architectures.

What Benefits For C# Plugin Architecture Have Been Unlocked?

The code examples in this article are essentially marrying approaches from two of the previous articles… so hopefully we have the best of both worlds! Let’s have a look:

• Can access WebApplicationBuilder instance from the WebApplication‘s dependency container.

• Can access IConfiguration instance from the WebApplication‘s dependency container.

• Can access WebApplication instance from the WebApplication‘s dependency container.

• Can resolve Autofac ContainerBuilder dependencies on the minimal APIs directly

• Can create separate Autofac modules (i.e. for plugin usage) that register minimal APIs directly onto the WebApplication instance

• Can get an extremely lightweight (one line!) entry point to our application. The core “skeleton” application code is fundamentally just setting up dependencies to be resolved.

All of these are boxes that I wanted to check before continuing to build plugins. With this infrastructure in place, I feel much more confident!

What Gaps Are Left For C# Plugin Architecture?

Of course, we need to look at both pros AND cons when we analyze things. Let’s dive in:

• We have two dependency containers to worry about. In theory, the usage of Autofac ComponentRegistryBuilder in ASP.NET Core should allow us to clone registrations between the two, but more complexity can potentially arise from this as we continue.

• We saw an interesting need to cache the WebApplication instance to avoid dependency recreation — are there other scenarios like this we haven’t hit yet?

• One of the general plugin architecture concerns: Being able to configure EVERYTHING with plugins can make some things harder to find and structure. Do we really need these little marker types to help organize ourselves?

Wrapping Up Autofac ComponentRegistryBuilder in ASP.NET Core

Overall, I’m quite happy with how using Autofac ComponentRegistryBuilder in ASP.NET Core has allowed us to progress our dependency injection patterns. This approach which I’ve highlighted in the article has made it significantly easier for me to go structure plugins the way that I’d like to in a C# plugin architecture. Not without tradeoffs — but I feel this pattern fits my needs.

If you found this useful and you’re looking for more learning opportunities, consider subscribing to my free weekly software engineering newsletter and check out my free videos on YouTube! Meet other like-minded software engineers and join my Discord community!

Want More Dev Leader Content?

• Follow along on this platform if you haven’t already!

• Subscribe to my free weekly software engineering and dotnet-focused newsletter. I include exclusive articles and early access to videos:
  SUBSCRIBE FOR FREE

• Looking for courses? Check out my offerings:
  VIEW COURSES

• E-Books & other resources:
  VIEW RESOURCES

• Watch hundreds of full-length videos on my YouTube channel:
  VISIT CHANNEL

• Visit my website for hundreds of articles on various software engineering topics (including code snippets):
  VISIT WEBSITE

• Check out the repository with many code examples from my articles and videos on GitHub:
  VIEW REPOSITORY

In this article, I highlight how to use Autofac’s ContainerBuilder in your ASP.NET Core application instead of the AutofacServiceProviderFactory. We’ll look at what you can and cannot do with this approach, versus the other approaches we have access to with dependency injection.

This will be part of a series where I explore dependency resolution with Autofac inside of ASP.NET Core. I'll be sure to include the series below as the issues are published:

• Part 1: AutofacServiceProviderFactory in ASP.NET Core - Problems With Dependency Injection

• Part 2: Autofac ContainerBuilder In ASP.NET Core – What You Need To Know

• Part 3: Autofac ComponentRegistryBuilder in ASP.NET Core - How To Register Dependencies

At the end of this series, you'll be able to more confidently explore plugin architectures inside of ASP.NET Core and Blazor -- which will be even more content for you to explore. Keep your eyes peeled on my Dometrain courses for a more guided approach to these topics later in 2023.

The Problem With AutofacServiceProviderFactory

To be fair, the section title is almost click-bait. I do think that AutofacServiceProviderFactory being used as the suggested way to set up Autofac in your ASP.NET Core applications is great for most applications. The great majority of developers who want to use Autofac as their dependency injection framework of choice would not run into many issues at all this way.

It does afford us the ability to:

• Access the WebApplicationBuilder (and anything available at this point in time)

• Access to the instance of IConfiguration (also available off the WebApplicationBuilder instance)

• Ability to pass dependencies onto minimal APIs

But the big issue for me: We can’t access the WebApplication instance. When I build plugin architectures in C#, in particular building ASP.NET Core applications, I like to have access to the WebApplication instance in order to register routes. This allows me to register minimal APIs from my plugins with ease, which technically only need access to an implementation of IEndpointRouteBuilder to get the handy syntax.

Can I register non-minimal APIs without this? Absolutely. Is there another way to provide similar syntax and not require a WebApplication instance? Very likely. But instead of trying to work around THAT problem, I wanted to see if I could just get access to the dependency I am interested in.

It was time to change the plan on how to set up my dependency container!

Exploring A Sample ASP.NET Core Application

Let’s look at a sample application so that we have some common ground to explore. If you’ve read the previous article, this will look similar — a variation of the sample weather application:

using Autofac;

using Microsoft.AspNetCore.Mvc;

// personal opinion:
// I absolutely love having the entry point of my
// applications being essentially:
// - make my dependencies
// - give me the primary dependency
// - use it
// - ... nothing else :)
ContainerBuilder containerBuilder = new();
containerBuilder.RegisterModule<MyModule>();

using var container = containerBuilder.Build();
using var scope = container.BeginLifetimeScope();
var app = scope.Resolve<WebApplication>();
app.Run();

internal record WeatherForecast(DateOnly Date, int TemperatureC, string? Summary)
{
    public int TemperatureF => 32 + (int)(TemperatureC / 0.5556);
}

internal sealed class MyModule : Module
{
    protected override void Load(ContainerBuilder containerBuilder)
    {
        containerBuilder.RegisterType<DependencyA>().SingleInstance();
        containerBuilder.RegisterType<DependencyB>().SingleInstance();
        containerBuilder.RegisterType<DependencyC>().SingleInstance();
        containerBuilder
            .Register(ctx =>
            {
                var builder = WebApplication.CreateBuilder(Environment.GetCommandLineArgs());
                return builder;
            })
            .SingleInstance();
        containerBuilder
            .Register(ctx => ctx.Resolve<WebApplicationBuilder>().Configuration)
            .As<IConfiguration>()
            .SingleInstance();
        containerBuilder
            .Register(ctx =>
            {
                var builder = ctx.Resolve<WebApplicationBuilder>();

                var app = builder.Build();
                app.UseHttpsRedirection();

                // FIXME: the problem is that the Autofac ContainerBuilder
                // was used to put all of these pieces together,
                // but we never told the web stack to use Autofac as the
                // service provider.
                // this means that the minimal API will never be able to
                // find services off the container. we would need to resolve
                // them BEFORE the API is called, like in this registration
                // method itself, from the context that is passed in.
                //DependencyA dependencyA = ctx.Resolve<DependencyA>();

                // FIXME: But... What happens if something wants to take a
                // dependency on the WebApplication instance itself? Once the
                // web application has been built, there's no more adding
                // dependencies to it!

                var summaries = new[]
                {
                    "Freezing", "Bracing", "Chilly", "Cool", "Mild", "Warm", "Balmy", "Hot", "Sweltering", "Scorching"
                };

                app.MapGet(
                    "/weatherforecast",
                    (
                        [FromServices] DependencyA dependencyA
                      , [FromServices] DependencyB dependencyB
                      , [FromServices] DependencyC dependencyC
                    ) =>
                    {
                        var forecast = Enumerable
                            .Range(1, 5)
                            .Select(index => new WeatherForecast
                            (
                                DateOnly.FromDateTime(DateTime.Now.AddDays(index)),
                                Random.Shared.Next(-20, 55),
                                summaries[Random.Shared.Next(summaries.Length)]
                            ))
                            .ToArray();
                        return forecast;
                    });

                return app;
            })
            .SingleInstance();
    }
}

internal sealed class DependencyA(
    WebApplicationBuilder _webApplicationBuilder);

internal sealed class DependencyB(
    WebApplication _webApplication);

internal sealed class DependencyC(
    IConfiguration _configuration);

One callout of this approach is that using the Autofac ContainerBuilder class as our primary dependency container affords us the opportunity to structure our entry point to just:

• Container creation

• Dependency registration

• Primary dependency resolution

• … Call a single method to start the app up!

This is, in my opinion, ideal application startup code. Why? Because you never need to come back here to touch it. Ever. No matter how many things you add in! And that’s all because you can scan assemblies to load more modules.

Again, this is a personal preference of mine and I am not trying to claim this should be everyone’s goal.

The Flaws of Autofac ContainerBuilder in ASP.NET Core

Of course, another approach that isn’t quite bulletproof. So let’s discuss what we DON’T get with this setup of Autofac:

• Service-resolved parameters passed on minimal APIs simply don’t work. The WebApplication that was built is not configured to use Autofac as the dependency injection framework!

• Like the previous article, we still can’t get the WebApplication instance on the dependency container… So we didn’t make any advancements specifically on accessing that.

But that’s mostly it! It’s not a terrible list of drawbacks, but the Autofac ContainerBuilder approach was not a silver bullet solution for us. So what did we get out of it? This video on Autofac will also help explain:

The Benefits of Autofac ContainerBuilder in ASP.NET Core

Pros and cons for everything we do! Now that we’ve seen the issues with Autofac ContainerBuilder in ASP.NET Core, it’s time to look at what advancements we got out of this:

• We can still access the WebApplicationBuilder and IConfiguration instances, so that’s a comparable benefit to using the AutofacServiceProviderFactory approach.

• We can get a very streamlined entry point to our program, which I really like to see. Container creation, registration, resolve your entry point method, and that’s all!

• Minimal APIs work, but not with dependencies. Still, we can pre-resolve the dependencies the minimal APIs want and pass those in at the time of method registration. See the commented code!

More Inversion for Plugin-Based ASP.NET Routes?

We saw that we could register minimal APIs within an Autofac registration method, but unfortunately, we cannot resolve dependencies from the container directly on the minimal API call itself. We could go build a dedicated class like the following that handles route definitions with dependencies being resolved automatically:

internal sealed class WeatherForecastRoutes(
    DependencyA _dependencyA
    // FIXME: still can't depend on this because
    // we can't get the WebApplication
//, DependencyB _dependencyB 
  , DependencyC _dependencyC)
{
    private static readonly string[] _summaries = new[]
    {
        "Freezing", "Bracing", // ...
    };

    public WeatherForecast[] Forecast()
    {
        var forecast = Enumerable.Range(1, 5).Select(index =>
            new WeatherForecast
            (
                DateOnly.FromDateTime(DateTime.Now.AddDays(index)),
                Random.Shared.Next(-20, 55),
                _summaries[Random.Shared.Next(_summaries.Length)]
            ))
            .ToArray();
        return forecast;
    }
}

The automatic resolution happens if we have this class AND the dependencies all on the same container. Then it’s just a matter of calling this code:

var weatherForecastRoutes = ctx.Resolve<WeatherForecastRoutes>();
app.MapGet("/weatherforecast2", weatherForecastRoutes.Forecast);

This still sucks a bit from a plugin perspective because we’d need to go resolve all of the route classes manually just to call the registration code like that — all stemming from the fact that these things can’t resolve their own access to the WebApplication instance.

But wait… What if we flip things around? What if we could resolve some interface like IRegisterRoutes and pass in the WebApplication instance?!

// NOTE: make sure to register WeatherForecastRouteRegistrar on the
// autofac container as IRegisterRoutes!

internal interface IRegisterRoutes
{
    void RegisterRoutes(WebApplication app);
}

internal sealed class WeatherForecastRouteRegistrar(
    WeatherForecastRoutes _weatherForecastRoutes) :
    IRegisterRoutes
{
    public void RegisterRoutes(WebApplication app)
    {
        app.MapGet("/weatherforecast2", _weatherForecastRoutes.Forecast);
    }
}

// TODO: add this to the autofac code where the 
// WebApplication instance is built:
foreach (var registrar in ctx.Resolve<IEnumerable<IRegisterRoutes>>())
{
    registrar.RegisterRoutes(app);
}

Now we don’t even need to care if the WebApplication instance is accessible to our plugins! Maybe the first version wasn’t so limiting after all? Maybe we’re onto something here… But the next article should explain this in more detail.

Wrapping Up Autofac ContainerBuilder in ASP.NET Core

In this article, I explored using an Autofac ContainerBuilder explicitly instead of using AutofacServiceProviderFactory as is normally suggested. We saw some similar benefits and drawbacks, but also a different set of things to consider. Each way can offer pros and cons depending on what you’re after in your application.

What was interesting was that if we’re trying to work towards plugins, we might not even need to access the WebApplication instance from our plugins at all! If we care about minimal APIs, this might still be limiting… but otherwise, we’re onto an interesting line of thinking!

If you found this useful and you’re looking for more learning opportunities, consider subscribing to my free weekly software engineering newsletter and check out my free videos on YouTube! Meet other like-minded software engineers and join my Discord community!

Want More Dev Leader Content?

• Follow along on this platform if you haven’t already!

• Subscribe to my free weekly software engineering and dotnet-focused newsletter. I include exclusive articles and early access to videos:
  SUBSCRIBE FOR FREE

• Looking for courses? Check out my offerings:
  VIEW COURSES

• E-Books & other resources:
  VIEW RESOURCES

• Watch hundreds of full-length videos on my YouTube channel:
  VISIT CHANNEL

• Visit my website for hundreds of articles on various software engineering topics (including code snippets):
  VISIT WEBSITE

• Check out the repository with many code examples from my articles and videos on GitHub:
  VIEW REPOSITORY

In this article, I highlight how to use AutofacServiceProviderFactory in your ASP.NET Core application along with what you can and cannot do with it. Having many options for dependency injection means that we have many pros and cons to analyze!

This will be part of a series where I explore dependency resolution with Autofac inside of ASP.NET Core. I'll be sure to include the series below as the issues are published:

• Part 1: AutofacServiceProviderFactory in ASP.NET Core - Problems With Dependency Injection

• Part 2: Autofac ContainerBuilder In ASP.NET Core – What You Need To Know

• Part 3: Autofac ComponentRegistryBuilder in ASP.NET Core - How To Register Dependencies

At the end of this series, you'll be able to more confidently explore plugin architectures inside of ASP.NET Core and Blazor -- which will be even more content for you to explore. Keep your eyes peeled on my Dometrain courses for a more guided approach to these topics later in 2023.

Dependency Injection: A Primer

What is Dependency Injection

Dependency Injection (DI) is a design pattern used in programming to make software systems easier to develop, test, and maintain. In C#, like in many other programming languages, dependency injection helps to decouple the components of your applications. Ideally, this leads to developing software that is more flexible and extensible.

Dependency Injection is about removing the hard-coded dependencies and making it possible to change them, either at runtime or compile time. This can be useful for many reasons, such as allowing a program to use different databases or testing components by replacing them with mock objects.

Consider a code example where we create an instance of a car with an engine:

public sealed class Car
{
    private readonly IEngine _engine;

    public Car()
    {
       // The Car class directly depends on the GasEngine class.
        _engine = new GasEngine();  
    }
}

We can instead “inject” the dependency via the constructor:

public sealed class Car
{
    private readonly IEngine _engine;

    // The engine is injected into the car via the constructor
    // so now there is no direct dependency on the Engine class,
    // but there is a dependency on the IEngine interface
    // which has nothing to do with the implementation
    public Car(IEngine engine)
    {
        _engine = engine;
    }
}

We can even use the idea of a “Dependency Container” that helps make this process seem a bit more magical by not requiring us to explicitly create instances of objects by passing in dependencies. Instead, the container allows us to resolve these dependencies. More on that in the next section!

What is Autofac?

Autofac is a popular inversion of control (IoC) container for .NET. It manages the dependencies between classes by injecting instances where needed, thereby facilitating a more modular and testable codebase. Autofac is used extensively in applications to implement the dependency injection pattern, allowing us to write cleaner, more maintainable code for the reasons I explained in the previous section.

There are other IoC containers to help us manage and resolve dependencies in our applications, including the built-in IServiceCollection, but Autofac is the one that I am most comfortable using. As .NET has evolved IServiceCollection has become more feature-rich, and with the gap in features between the two closing, Autofac is still one that I like using in my development.

What is the AutofacServiceProviderFactory in ASP.NET Core?

The AutofacServiceProviderFactory is a specific component in the Autofac library designed for integrating Autofac with the built-in dependency injection (DI) system in ASP.NET Core. Essentially, it acts as a bridge allowing you to use Autofac as the DI container instead of the default one provided by Microsoft.

I’ve written about this before in this article:

Exploring A Sample ASP.NET Core Application

I wanted to make sure we had a common application to refer to when I get into more of the technical details of what we do and do not get with AutofacServiceProviderFactory. The following code is the sample weather app we get from Visual Studio when creating a new ASP.NET Core web API, but I’ve modified it slightly to showcase some of the behavior we get with AutofacServiceProviderFactory:

using Autofac;
using Autofac.Extensions.DependencyInjection;

using Microsoft.AspNetCore.Mvc;

var builder = WebApplication.CreateBuilder(args);
builder.Host.UseServiceProviderFactory(new AutofacServiceProviderFactory(containerBuilder =>
{
    containerBuilder
        .RegisterInstance(builder)
        .SingleInstance();
    containerBuilder
        .Register(ctx => ctx.Resolve<WebApplicationBuilder>().Configuration)
        .SingleInstance();
    // FIXME: we can't do this because the WebApplicationBuilder
    // the WebApplicationBuilder is responsible for building the
    // WebApplication, so we can't do that manually just to add
    // it into the container
    //containerBuilder
    //    .Register(ctx =>
    //    {
    //        var app = ctx.Resolve<WebApplicationBuilder>().Build();
    //        app.UseHttpsRedirection();
    //        return app;
    //    })
    //    .SingleInstance();
    containerBuilder.RegisterType<DependencyA>().SingleInstance();
    containerBuilder.RegisterType<DependencyB>().SingleInstance();
    containerBuilder.RegisterType<DependencyC>().SingleInstance();
    //containerBuilder
    //    .RegisterBuildCallback(ctx =>
    //    {
    //        // FIXME: this was never registered
    //        var app = ctx.Resolve<WebApplication>();

    //        var summaries = new[]
    //        {
    //            "Freezing", "Bracing", "Chilly", "Cool", "Mild", "Warm", "Balmy", "Hot", "Sweltering", "Scorching"
    //        };

    //        app.MapGet(
    //            "/weatherforecast",
    //            (
    //                [FromServices] DependencyA dependencyA // this will work
    //              , [FromServices] DependencyB dependencyB // FIXME: this will fail!!
    //              , [FromServices] DependencyC dependencyC // this will work
    //            ) =>
    //            {
    //                var forecast = Enumerable.Range(1, 5).Select(index =>
    //                    new WeatherForecast
    //                    (
    //                        DateOnly.FromDateTime(DateTime.Now.AddDays(index)),
    //                        Random.Shared.Next(-20, 55),
    //                        summaries[Random.Shared.Next(summaries.Length)]
    //                    ))
    //                    .ToArray();
    //                return forecast;
    //            });
    //    });
}));

// FIXME: we can't get the WebApplication into the
// Autofac container, because it's already been built.
// this means if we have anything that wants to take a
// dependency on the WebApplication instance itself, we
// can't resolve it from the container.
var app = builder.Build();
app.UseHttpsRedirection();

var summaries = new[]
{
    "Freezing", "Bracing", "Chilly", "Cool", "Mild", "Warm", "Balmy", "Hot", "Sweltering", "Scorching"
};

app.MapGet(
    "/weatherforecast",
    (
        [FromServices] DependencyA dependencyA // this will work
      , [FromServices] DependencyB dependencyB // FIXME: this will fail!!
      , [FromServices] DependencyC dependencyC // this will work
    ) =>
    {
        var forecast = Enumerable.Range(1, 5).Select(index =>
            new WeatherForecast
            (
                DateOnly.FromDateTime(DateTime.Now.AddDays(index)),
                Random.Shared.Next(-20, 55),
                summaries[Random.Shared.Next(summaries.Length)]
            ))
            .ToArray();
        return forecast;
    });

app.Run();

internal record WeatherForecast(DateOnly Date, int TemperatureC, string? Summary)
{
    public int TemperatureF => 32 + (int)(TemperatureC / 0.5556);
}

internal sealed class DependencyA(
    WebApplicationBuilder _webApplicationBuilder);

internal sealed class DependencyB(
    Lazy<WebApplication> _webApplication);

internal sealed class DependencyC(
    IConfiguration _configuration);

You should note that I’ve modified the weather API itself to take in 3 dependencies that we want to resolve from the service list. [FromService] is in fact not required here, but it makes the error messages more clear if you were to go run this and want to understand where and why it fails.

But wait… why does it fail?! Keep on readin’ and follow along with this video on Autofac to find out more:

What Can We Get With AutofacServiceProviderFactory in ASP.NET Core?

Let’s start off with what we get from this setup because I do think that this is the typical path. To be clear, there’s nothing “wrong” with this approach, but you need to understand where dependencies are registered and resolved, and therefore what works with your container:

• We have access to the WebApplicationBuilder on the Autofac ContainerBuilder instance. This allows us to have services depending on the app builder instance, which means we can have modules and/or plugins that want to setup information on the app builder or otherwise read state from the app builder.

• With that said, we have access to the IConfiguration instance from the WebApplicationBuilder because it’s exposed on the web app builder itself.

• We get the ability to resolve dependencies from the container that are defined directly on our minimal APIs! In the example I shared above, the dependency classes A through C are all types that can be resolved from the container automatically on the minimal API. There’s a catch for one of these which we’ll cover, but the point is their registrations can be seen by our minimal API.

In general, this is probably “good enough” for most situations if you just want to use Autofac for your ASP.NET Core application. However, this is limiting for the style of development that I like to do.

What’s Missing With AutofacServiceProviderFactory in ASP.NET Core?

Now that we’ve seen the goodness that we get, let’s discuss where there are some drawbacks. They’re essentially already highlighted in the code with FIXME comments, but it’s worth elaborating on them in more detail here. Again, this is not to suggest this is the “wrong” way to do it, just that you have some considerations to make:

• The WebApplication instance is not something that we can resolve from the container. That is, if you ever want to have classes automatically resolve from the dependency container, they cannot take a dependency on WebApplication. This is because this instance is never registered onto the container and therefore cannot be automatically injected for us.

• We can’t overcome this behavior by calling the Build() method manually on the WebApplicationBuilder inside of an Autofac registration. This is because the chain of registrations executes once we call Build() on the web application builder OUTSIDE of the container, which then handles the rest of the application being built. Said another way, this creates a bit of a circular dependency on the responsibilities that need to be handled.

• Because we cannot resolve the WebApplication instance from the dependency container, we cannot create plugins that add their own routes to the application using the minimal API route registration syntax. If this is indeed possible to do, it would have to be using a different API and instance of a different type since the WebApplication instance is not accessible to us via the container.

• Based on the above points, we cannot have dependencies on the routes like DependencyB in the example above. This is because this type has a dependency on WebApplication and the container simply does not know about it. In the future articles, you’ll see examples of this pattern coming up again so it’s worth mentioning in this article for reference.

Many of these are not a concern for folks building typical applications. However, as someone that builds mostly plugin architecture applications, this is very limiting for me!

Wrapping Up AutofacServiceProviderFactory in ASP.NET Core

In this article, I provided a brief overview of dependency injection and Autofac within ASP.NET Core. The primary takeaway was looking at what you do and do not get when using AutofacServiceProviderFactory in ASP.NET Core. While the limitations of this are minimized for the average application, this does not work well for a plugin architecture that wants to extend the API routes via plugins.

If you found this useful and you’re looking for more learning opportunities, consider subscribing to my free weekly software engineering newsletter and check out my free videos on YouTube! Meet other like-minded software engineers and join my Discord community!

Want More Dev Leader Content?

• Follow along on this platform if you haven’t already!

• Subscribe to my free weekly software engineering and dotnet-focused newsletter. I include exclusive articles and early access to videos:
  SUBSCRIBE FOR FREE

• Looking for courses? Check out my offerings:
  VIEW COURSES

• E-Books & other resources:
  VIEW RESOURCES

• Watch hundreds of full-length videos on my YouTube channel:
  VISIT CHANNEL

• Visit my website for hundreds of articles on various software engineering topics (including code snippets):
  VISIT WEBSITE

• Check out the repository with many code examples from my articles and videos on GitHub:
  VIEW REPOSITORY

In this article, I wanted to share with you my journey from working at startup companies all the way to being a Principal Software Engineering Manager at Microsoft. I’d love to share with you my interview experiences and my observations about what I value (and what I dislike) from startups and Big Tech.

Remember that your career journey is for you to own. Don’t try to copy someone else’s life, just learn from their experiences and take charge of your own. There’s no “wrong” path. Every path is unique.

I wrote this article for my good friend, Muhammad Waseem. He graciously offered to include my story in one of his newsletters, and I thought it would be such an awesome opportunity to share with his audience. My version of the article has been slightly adapted so I can share other relevant content for my own audience.

Muhammad, my friend, thank you for thinking about me!

My Background

I went to the University of Waterloo for computer engineering. While I didn’t like my classes at all, my 6 internships really solidified that I wanted to be in this industry. I spent my internships mostly at startups or small companies, but in completely different sectors so I could get different experiences.

Action: Take advantage of internships if you have the option!

Action: Use your internships to explore different domains and styles of companies!

My first real full-time software engineering job outside of university was a digital forensics company, now called Magnet Forensics, that was just starting out. This was the first time I started to have a good mix of autonomy and solid leadership mixed together because up until this point with work, I felt it hard to stay motivated in what I was doing for work.

This company had also taken a chance on me because they appreciated my existing skills and way of thinking but knew that I had zero experience in digital forensics. This was also going to be one of the first times in my career that I really noticed “Oh crap, I don’t know how to do any of this…” only to realize that after several months I was on my way to building expertise.

Action: Find companies and leadership that you align with. This may take time and experience in industry.

Action: Don’t be afraid to jump into new challenges. It’s the best way to learn.

I became a technical manager within several months of being at this company, which required my time was spent coding and managing. But this was all due to one critical software engineering skill that I think everyone should invest more time in: Communication.

Action: Work on your soft skills, not just your technical skills

Check out this video with Callie Buruchara for more details on why communication is so valuable:

Getting into Big Tech

This was one of my least favorite things I’ve done in the past few years. I find that I don’t do a great job selling myself to recruiters, and it feels unnatural to discuss my accomplishments. I needed to spend time updating my resume, which would include highlighting some of the biggest accomplishments in my career up to this point.

Action: Update your resume with high impact work. Pick relevant experiences to what you’re applying for.

I applied to some of the popular Big Tech companies and after several weeks had interviews that were lined up over a few weeks. In order to do this, I chose the route of going onto their career pages and going through the typical paths. I felt that I had solid work experience and based on historically what I had heard, it shouldn’t be too difficult to hear back.

Action: Most (if not all) companies have career pages that show you what they are actively hiring for. Use those.

Admittedly, the job market now is extremely different than it was when I was applying. You need to do everything you can to stand out. This may be an EXTREMELY difficult time to apply to Big Tech companies because of the volume of people trying — so I do not want you to be discouraged. It may not currently be in your favor, but that doesn’t mean you can’t focus on things that are in your control.

Action: Give some consideration to companies that aren’t Big Tech. They can offer incredible opportunities and there’s less competition.

Networking can be very powerful — so get in touch with recruiters as much as you can. You may have luck connecting with hiring managers, but from my personal experience, I have to direct every single person to the Microsoft careers page anyway.

Action: Always try to be networking! Build relationships with recruiters!

With that said, if you’re interested in Microsoft, my biggest advice would be to:

• Use the Microsoft careers page to find jobs you’re interested in

• Use LinkedIn to connect with recruiters

• Use LinkedIn to connect with employees in the space

When you connect with the employees in the space DO NOT ask them to refer you. They don’t even know you, so they should not be referring you. Instead, see if you can get some time from them to learn about what it’s like working in that space. Build a true connection and use it as a learning opportunity.

Interviewing – Exactly What You’d Expect

I’m an engineering manager and I was applying for engineering manager roles… But you bet that I was still being interviewed like a Principal-level software engineer AND with management components added in. There are many similarities with how I would be interviewed compared to an individual contributor software engineer!

I was grinding LeetCode questions every day. Systems design questions. Behavioral questions. All of it. Every day for multiple hours. This was extreme for me because I hadn’t interviewed in nearly a DECADE. And every single big tech company was similar. Algorithms. Systems design. Behavioral. Much of what you read or hear online about this is spot on.

Action: Familiarize yourself with coding questions (LeetCode), distributed design questions, and project/behavioral questions

Action: Set aside time to practice as much as you can.

You need to be prepared to ask clarifying questions in the technical part. I hate these types of technical interview questions because I’ve seen people practice them like crazy, get hired, and then struggle as a developer because they just managed to train themselves well at interviewing. Something to keep in mind.

Action: When you’re practicing, try verbally asking clarifying questions and give yourself some constraints. You need to get good at this.

I only had one of my interviews, but that’s okay. It can happen to anyone. Ultimately, I chose Microsoft because everything I had heard about the work culture was aligned with what I wanted.

These two livestreams focus on getting noticed and preparing for interviews, and I think they’re very valuable to go alongside this:

And the second one focusing on the interview process itself, here:

Big Tech – Final Thoughts

I want to close out this article by bringing back what I said in the introduction:

There’s no “wrong” path. Every path is unique.

My philosophy in software engineering is that there are pros and cons to everything. Where we work is no different. Some similarities and differences from my own experiences:

• You might be working on platforms and/or internal systems compared to user-facing offerings. Figure out what you prefer!

• You can find a lot of meaning in what you’re doing at big or small companies, but it’s often easier to feel that you have a bigger relative impact at a smaller company

• How much autonomy you have can vary from company to company — usually smaller companies there’s more flexibility and autonomy because there’s less bureaucracy built in.

• From team to team, or company to company, you might notice the rate at which you can ship features/fixes is different. This can be a VERY big quality of life to consider as a software engineer.

• Big tech has very ironed out career ladders whereas startups it can be more chaotic — but your level vs how much REAL experience you gain are not always aligned.

• How you interview for Big Tech is well documented but for startups and smaller companies the interview processes may look quite different

There are many more things to compare — but I want you to know that many people will value these things differently. What we value in life changes as well. I’m very respectful of my work-life time boundaries now. No more 16-hour days.

But a question I’d leave you with is… What do you truly value in your career? In your life?

Want More Dev Leader Content?

• Follow along on this platform if you haven’t already!

• Subscribe to my free weekly software engineering and dotnet-focused newsletter. I include exclusive articles and early access to videos:
  SUBSCRIBE FOR FREE

• Looking for courses? Check out my offerings:
  VIEW COURSES

• E-Books & other resources:
  VIEW RESOURCES

• Watch hundreds of full-length videos on my YouTube channel:
  VISIT CHANNEL

• Visit my website for hundreds of articles on various software engineering topics (including code snippets):
  VISIT WEBSITE

• Check out the repository with many code examples from my articles and videos on GitHub:
  VIEW REPOSITORY

This guide will focus on getting MudBlazor with Blazor interactive SSR set up and configured in a new Blazor project in dotnet 8. This is hopefully applicable for future versions of dotnet, as long as this doesn’t change behavior dramatically. Following this guide will ideally prevent you from running into all sorts of fun Blazor render mode issues.

What is MudBlazor?

Like with all user-interface tech stacks, it’s very common to have reusable control libraries. One such control library is MudBlazor. In their own words:

MudBlazor is an ambitious Material Design component framework for Blazor with an emphasis on ease of use and clear structure. It is perfect for .NET developers who want to rapidly build web applications without having to struggle with CSS and Javascript. MudBlazor, being written entirely in C#, empowers you to adapt, fix or extend the framework. There are plenty of examples in the documentation, which makes understanding and learning MudBlazor very easy.

Originally, I went looking for MudBlazor because I wanted to develop more of a customized list view in my application. However, the default controls didn’t seem like they did a great job for what I wanted. I’ve spent well over a decade building user interface applications in WinForms and WPF, so I’m no stranger to control libraries. But that’s exactly why I figured I shouldn’t need to roll my own — someone else has got this covered!

What Are Blazor Render Modes?

Blazor Web Apps use different render modes to control where and how components are rendered. The modes include:

1. Static Server: Renders components on the server without interactivity.

2. Interactive Server: Also renders on the server but allows interactivity using Blazor Server.

3. Interactive WebAssembly: Renders interactively on the client-side using Blazor WebAssembly.

4. Interactive Auto: Starts with server-side rendering and shifts to client-side on subsequent interactions after the Blazor bundle is downloaded.

These render modes are set using the @rendermode directive in the component’s code. More details on configuring and applying these modes can be found on the Microsoft documentation page.

This article is not focusing on which render mode is better or worse, nor will I be doing an in-depth analysis. I wanted to provide this context so that you can see we’ll be using Interactive Server render mode to get Blazor server-side rendering (SSR) with our app.

With that said, the distinction between client-side and server-side rendering is important for performance and interactivity:

• Client-side rendering (WebAssembly mode): Components are executed and rendered directly in the user’s browser using WebAssembly. This mode offers a richer, more interactive experience as it doesn’t require a round-trip to the server for UI updates. However, it involves a larger initial download and more resource consumption on the client side.

• Server-side rendering (Server mode): Components are executed and rendered on the server. The rendered UI is delivered as static HTML to the client’s browser, and interactivity is maintained through a SignalR connection that manages event handling and UI updates. This mode minimizes client-side resources since the client doesn’t execute the component logic, but it relies heavily on the network connection to the server, which can impact responsiveness and user experience.

Each mode has its use case depending on the application’s needs for performance, scalability, and complexity. The focus of this article is on a server rendering mode not because I claim it’s superior, but because it’s what I needed for my own development purposes.

How to Get MudBlazor with Blazor Interactive SSR Working

The following sections will give you the step-by-step actions required to get MudBlazor with Blazor interactive SSR working. You can follow along with this MudBlazor video tutorial as well:

New Blazor Project Setup

The first thing that we need to do is create our project in Visual Studio. To do that, we’re going to select the “Blazor Web App” project template from Visual Studio.

Next, we’ll want to ensure we select the correct render mode. We want it to be “Server” as we see in the screenshot below.

The other options are of course up to you. If indeed you need another render mode, then the rest of this guide is not for you as we’re strictly focused on server-side render (SSR) mode. Remember, the reason that I wrote this is that I thought I had to use the dual mode for supporting MudBlazor because the instructions I received didn’t seem to line up exactly.

Configuring Mud Blazor with Blazor Interactive SSR

Now that we have our project setup, it’s time to get going with setting up MudBlazor. I should note that they DO have instructions that you can follow on their GitHub — so if you’re getting stuck with my guide, go read theirs. However, I followed theirs the first time and still ran into some fun hiccups because I didn’t know what project to create. Not the fault of MudBlazor nor the fault of Blazor; Just Nick’s fault.

Step one will be getting the nuget package installed:

dotnet add package MudBlazor

And once installed, we only have a couple of spots to go update! Starting off, to make the MudBlazor accessible in our razor files by default, we can add the following to _Imports.razor:

@using MudBlazor

Slightly separate guidance from what they list on their GitHub, but we can place the following code in the <head> block of App.razor

<link href="https://fonts.googleapis.com/css?family=Roboto:300,400,500,700&display=swap" rel="stylesheet" />
<link href="_content/MudBlazor/MudBlazor.min.css" rel="stylesheet" />
<MudThemeProvider/>
<MudDialogProvider/>
<MudSnackbarProvider/>

Next, we add the following to the <body> block of the same file:

<script src="_content/MudBlazor/MudBlazor.min.js"></script>

And finally, we need these two lines into program.cs to enable dependency injection for MudBlazor:

using MudBlazor.Services;
builder.Services.AddMudServices();

Using MudBlazor with Blazor Interactive SSR

Now that we’re all configured, we can use MudBlazor! I started off with the sample application to prove this all out, so I figured I’d change the default “counter” page to use MudBlazor controls.

Here’s the change to that code that I made:

@page "/counter"

<PageTitle>Counter</PageTitle>

<h1>Counter</h1>

<MudText Typo="Typo.h6">
    Current count: @currentCount
</MudText>
<MudButton
    Variant="Variant.Filled" 
    Color="Color.Primary" 
    OnClick="ButtonOnClick">
    Click Me!
</MudButton>

@code 
{
    private int currentCount = 0;

    void ButtonOnClick()
    {
        currentCount++;
    }
}

And if you want to see it in action:

Wrapping Up MudBlazor with Blazor Interactive SSR

This was just a simple guide to get you up and running using MudBlazor with Blazor interactive SSR! If you start off with the Blazor server-side rendering project instead of the dual mode where it’s auto server and webassembly, you’ll have a much better time. However, maybe you know what you’re doing significantly better than me and you’re ready to jump into the dual render-mode support — but I certainly was not!

If you found this useful and you’re looking for more learning opportunities, consider subscribing to my free weekly software engineering newsletter and check out my free videos on YouTube! Meet other like-minded software engineers and join my Discord community!

Want More Dev Leader Content?

• Follow along on this platform if you haven’t already!

• Subscribe to my free weekly software engineering and dotnet-focused newsletter. I include exclusive articles and early access to videos:
  SUBSCRIBE FOR FREE

• Looking for courses? Check out my offerings:
  VIEW COURSES

• E-Books & other resources:
  VIEW RESOURCES

• Watch hundreds of full-length videos on my YouTube channel:
  VISIT CHANNEL

• Visit my website for hundreds of articles on various software engineering topics (including code snippets):
  VISIT WEBSITE

• Check out the repository with many code examples from my articles and videos on GitHub:
  VIEW REPOSITORY

In this article, I’ll explain the very basics of how to structure try catch blocks and what each block is responsible for. The code is simple and aims to help explain some of the basic concepts to beginners working in C#. If that sounds like you, read on!

Overview of Exception Handling in C#

Let’s face it: there are going to be exceptions in our C# applications and services at some point. We hate to admit it, but it’s a reality that we have to understand how to work with.

Exception handling in C# is done by using what’s called a try/catch block. So try catch in C# is how we set up code to have some type of protection and define the logic for how we want to deal with those exceptions.

The following sections will explain the two main pieces, try and catch, and later on we’ll see an extra third component we can add to the try catch blocks we create in C#. You can follow along with this video on how to handle exceptions with try/catch blocks in C# as well:

The Try Block

The try block is the first important part of our exception handling that we need to look at. It serves the purpose of enclosing the code that might potentially throw an exception. By placing the code within a try block, we ensure that any exceptions that occur can be caught and handled appropriately — but it’s not handled by this block, this block just tells us what will get handled.

The try block is structured using the keyword “try”, followed by a set of curly braces that contain the code we want to monitor for exceptions. This code is often referred to as the “protected code”, as it is within this block that we anticipate will be potentially throwing exceptions. Here’s an example of a try block in C#:

try
{
    // Code that might throw an exception
    int result = Divide(10, 0);
    Console.WriteLine("The result is: " + result);
}

In this example, we have a function called “Divide” that takes two integers as parameters and attempts to perform a division operation. However, if the second parameter is zero, it will throw a divide by zero exception. By enclosing this code within a try block, we can catch and handle this exception appropriately — but we need another block to actually handle it! And that’s where we’re headed in the next section!

The Catch Block

The main purpose of the catch block is to provide a mechanism for handling exceptions gracefully. The try block allows us to define what we want to protect, and the catch block allows us to define what we’ll handle and how we’ll handle it.

When an exception is thrown, the catch block allows us to specify the actions to be taken in response to that exception. These actions could include logging the exception, displaying an error message to the user, or taking any other necessary corrective measures. The choice is yours!

To catch a specific type of exception, we use the catch keyword followed by the exception type we want to handle. This allows us to handle different exceptions in different ways, tailoring our response based on the specific type of exception.

Here’s an example of a catch block that handles a specific exception type, in this case, the DivideByZeroException:

try
{
    int result = 10 / 0; // This will throw a DivideByZeroException
}
catch (DivideByZeroException ex)
{
    Console.WriteLine("An error occurred: " + ex.Message);
}

In this example, the code within the try block attempts to divide the number 10 by 0, which will result in a DivideByZeroException. The catch block catches this exception and executes the code within its block, which in this case, simply writes an error message to the console, displaying the message provided by the exception.

You can also use a base exception class or omit the exception portion altogether to catch all (well, almost all) exceptions:

try
{
}
catch (Exception ex)
{
    // this will catch all catchable exceptions
}

// OR

try
{
}
catch
{
    // note that we don't have an exception instance in this case!
}

Handling Multiple Exceptions

If one exception can be thrown from a called piece of code, odds are that many can. As a result, it’s common to encounter scenarios where multiple types of exceptions can occur within a single try block. These exceptions may arise due to different errors or exceptional situations that need to be handled appropriately. In this section, I’ll discuss how to handle multiple exceptions by using either multiple catch blocks or a single catch block with multiple exception types. Let’s see how!

Multiple Catch Blocks Approach

When handling multiple exceptions, one approach is to use multiple catch blocks. Each catch block is responsible for handling a specific type of exception. By using this approach, you can specify separate code blocks to handle different exceptions based on their respective types.

Here is an example that demonstrates the multiple catch blocks approach:

try
{
    // Code that may throw exceptions
}
catch (ArgumentNullException ex)
{
    // Handle ArgumentNullException
}
catch (DivideByZeroException ex)
{
    // Handle DivideByZeroException
}
catch (FormatException ex)
{
    // Handle FormatException
}

In the above example, the catch block following the try block will catch and handle any ArgumentNullException that occurs. Similarly, the catch blocks for DivideByZeroException and FormatException will handle their respective exceptions.

Single Catch Block with When Filtering

Another approach for handling multiple exceptions is to use a single catch block that can handle multiple exception types. This approach can be useful when you want to handle multiple exceptions in the same way without writing separate catch blocks for each one.

Here is an example that demonstrates the single catch block approach:

try
{
    // Code that may throw exceptions
}
catch (Exception ex) when // look at this fancy keyword!
(
    ex is ArgumentNullException ||
    ex is DivideByZeroException || 
    ex is FormatException
)
{
    // Handle ArgumentNullException, DivideByZeroException, and FormatException
}

In the above example, the catch block will handle any ArgumentNullException, DivideByZeroException, or FormatException that occurs within the try block. This is because we’ve placed a filter onto the exception handler using the when keyword!

I should note that you can do more filtering than just type-checking with the when keyword. You’re able to examine the different properties for the exception instance and create filters accordingly. If you needed to filter by a certain exception message or error code on a particular exception type, you can do that with the when keyword.

The Finally Block

The finally block in C# is used to define a section of code that will always be executed, regardless of whether an exception occurred or not. Its purpose is to ensure that certain tasks, such as releasing resources or performing cleanup operations, are always carried out, regardless of the outcome of the try block.

The finally block is executed after the try and catch blocks, whether an exception is thrown or not. It’s written with the keyword “finally” followed by a set of curly braces {}. Any code within these braces will be executed immediately after the catch block finishes.

Finally Block Use Case

One common use case for the finally block is to release any resources that were acquired within the try block. This could include closing file handles, database connections, network sockets, or any other resource that needs to be freed up. By placing the cleanup code in the finally block, you can ensure that it will be executed even if an exception is thrown in the try block.

Here is an example that demonstrates the use of the finally block for resource cleanup:

try
{
    // Code that could potentially throw an exception
    // Acquiring resources
    // Performing operations
}
catch(Exception ex)
{
    // Exception handling code
    // Logging or displaying error messages
}
finally
{
    // Code to release resources
    // Closing file handles, database connections, etc.
}

In this example, if an exception is thrown in the try block, the program flow will jump to the catch block to handle the exception. However, regardless of whether an exception is thrown or not, the code within the finally block will always be executed afterwards. This ensures that any acquired resources are properly released, preventing resource leaks and maintaining the stability of the program.

Alternative to Finally Blocks: IDisposable

The finally block that we can use when it comes to try catch in C# is very helpful — but try/catch syntax is already a bit clunky to begin with. It’s a common pattern that we want to clean up resources and if we’re being defensive, we want to make sure that we clean them up even when we have error scenarios.

We can use the IDisposable interface and a using block to help support this. So instead of requiring a finally block to clean things up, you could have code inside of a Dispose() method on the object that implements IDisposable. The code would be simplified to this:

public class MyClass : IDisposable
{
    public void Dispose()
    {
        // TODO: do your cleanup... same 
        // stuff that you might have wanted
        // in your finally block!
    }
}

using (Myclass myClass = new())
{
    // do stuff with myClass
}

// dispose runs after we leave the block

This is a lot less clunky, in my opinion than a whole try/finally block to support cleanup — but of course, this will not catch errors just ensure you can still run cleanup code. We can simplify this further with implicit using now where the Dispose() method runs when the variable goes out of scope:

public void SomeMethod()
{
    // implicit using...
    using Myclass myClass = new();

    // do stuff with myClass

    // dispose runs at the end here since the variable goes out of scope
}

Considerations for Try Catch in C#

Now that you’ve seen several different ways we can use try catch in C# as well as some different use cases, let’s talk about some considerations. We’ve seen the tools we have to use, but some guidance on using them appropriately seems fitting:

1. Is it REALLY exceptional?: Consider if the exception you’re catching is truly exceptional. Unfortunately, many libraries and programs have exceptions thrown that are not truly exceptional behavior for an application. This can complicate logic and slow things down. So if you don’t need to throw them, don’t. But you also might need to catch them because you don’t want the entire program to terminate.

2. Catch All vs Catch Specific: Many people frown upon using a try/catch block that attempts to catch all exceptions. The argument is that you could be masking an underlying problem with a blanket handler. However, there are absolutely situations (many of which I’ve used in a professional setting) where we’ve been better off with a catch-all. Some things we are calling are outside of our control with respect to the errors they throw, and if you don’t need your entire application or service to end… then you need to handle them.

3. Proper Cleanup: Consider if you need something like a finally block or to use the dispose pattern. Remember, using the dispose pattern can help clean up the code but alone it does not prevent exceptions from being thrown.

4. Logging & Telemetry: You’ll not only want to understand recovery patterns when using try catch in C#, but you should consider if you need to be doing something with this error information. If you have a live service running in production, there are many cases where you’ll want to know what’s going wrong or what can be improved. Logging and telemetry can help!

Wrapping Up Try Catch in C#

Now you’ve had a chance to see the basics of try catch in C#! I’ve aimed to help familiarize you with the purpose of the different blocks, and introduced the finally block as well! With some basic code examples to refer to along with some extra considerations to keep in mind when programming, you’re all set to start catching exceptions in your code!

If you found this useful and you’re looking for more learning opportunities, consider subscribing to my free weekly software engineering newsletter and check out my free videos on YouTube! Meet other like-minded software engineers and join my Discord community!

Want More Dev Leader Content?

• Follow along on this platform if you haven’t already!

• Subscribe to my free weekly software engineering and dotnet-focused newsletter. I include exclusive articles and early access to videos:
  SUBSCRIBE FOR FREE

• Looking for courses? Check out my offerings:
  VIEW COURSES

• E-Books & other resources:
  VIEW RESOURCES

• Watch hundreds of full-length videos on my YouTube channel:
  VISIT CHANNEL

• Visit my website for hundreds of articles on various software engineering topics (including code snippets):
  VISIT WEBSITE

• Check out the repository with many code examples from my articles and videos on GitHub:
  VIEW REPOSITORY

In this article, I’ll provide you code examples to be able to convert a string to a byte array in C# — and back again! You’ll also learn about some of the nuances of character encodings to look out for!

Encoding and Decoding in C#

If we want to convert a string to a byte array — or go the other way — we need to understand the concept of encoding and decoding. In software engineering, encoding refers to the process of transforming a string into a sequence of bytes, while decoding involves the reverse process of transforming bytes back into a string. Simple, right?

Remember that strings are a sequence of characters, and the concept of a character makes a lot of sense to us as readers, but computers understand bytes. Characters themselves can be represented by numbers in computers so when we want to work with strings at a lower level, such as when sending data over a network or storing it in a file, we need to convert the string into a byte array.

Encoding comes into play when converting strings to byte arrays. It determines how the characters in the string are represented as bytes. The encoding scheme defines the mapping between characters and their byte representations. Common encoding schemes include UTF-8, UTF-16, ASCII, and Unicode.

Choosing the correct encoding is important because different encoding schemes support different sets of characters. For example, ASCII only supports the basic English alphabet (with a few more characters), while UTF-8 and UTF-16 are capable of representing characters from multiple languages and scripts. More on this later though since I know you’re eager for some code!

Choosing an Encoding for String to Byte Array Conversion

When converting strings to byte arrays in C#, one of the most important things to consider is character encoding. Character encoding determines the mapping between characters and byte values, and if you’re considering transforming data one way then you may want to put some thought into how to transform it back!

What’s that supposed to mean? Well, if we use a data transform — let’s say taking a string and transforming it to bytes with an ASCII encoding — if there is not a mapping of a particular character to a byte representation we lose that data in the result. Now what happens if you want to go the other way and get your byte array back to a string?

Data is missing!

In C#, there are various encodings available, including ASCII, UTF-8, and UTF-16, each with its specific characteristics and usage scenarios. Let’s explore these encodings and see how they can be used for string to byte array conversion.

ASCII Encoding

ASCII encoding represents characters using 7 bits, allowing for a total of 128 different characters. It’s primarily suitable for handling basic English characters and is more space-efficient compared to other encodings. Here’s an example of converting a string to a byte array using ASCII encoding:

string text = "Hello, World!";
byte[] asciiBytes = Encoding.ASCII.GetBytes(text);

In many modern applications, ASCII may not be what you’re after. This is especially true if you have users across the globe in locales that are not English. That’s not to say that ASCII cannot be used, but you’ll want to be careful about what data you ASCII encode so as to not lose information during the encoding transform.

So keep in mind that the ASCII character set represents characters using a 7-bit encoding scheme, allowing for a total of 128 unique characters. However, with the growing need for internationalization and multilingual support, ASCII alone is insufficient to represent all characters effectively.

Good thing we have some other options coming right up!

UTF-8 Encoding

UTF-8 encoding is a variable-length encoding scheme that can represent any Unicode character. It’s widely used for encoding text in various languages and is backward compatible with ASCII. It uses fewer bytes for representing ASCII characters but may require more bytes for non-ASCII characters. Here’s an example of converting a string to a byte array using UTF-8 encoding:

string text = "Привет, мир!";
byte[] utf8Bytes = Encoding.UTF8.GetBytes(text);

UTF-16 Encoding

UTF-16 encoding represents characters using either 2 or 4 bytes, making it capable of representing any Unicode character. It’s commonly used by applications that need to handle multilingual text or when interoperability with other systems is required. The encoding can be little-endian or big-endian, with the former being more prevalent. Here’s an example of converting a string to a byte array using UTF-16 encoding:

string text = "こんにちは、世界！";
byte[] utf16Bytes = Encoding.Unicode.GetBytes(text);

UTF-8 Encoding vs UTF-16 Encoding – What’s The Difference?

Each of these encodings is variable width, and their size gives them different characteristics when we consider different alphabets.

Starting with UTF-8, it’s variable-width and backward-compatible with ASCII. In this encoding:

• ASCII characters, which are on the range U+0000 to U+007F, take only 1 byte.

• In the next range, code points U+0080 to U+07FF take twice as much space at 2 bytes each.

• Code points U+0800 to U+FFFF take one more byte, bringing us up to 3 bytes

• And finally, code points U+10000 to U+10FFFF take 4 bytes.

This can be very effective for English text because those characters will take up minimal space. However, when it comes to Asian text it’s not ideal for the exact opposite reason.

Because UTF-16 has code points from U+0000 to U+FFFF take 2 bytes and code points U+10000 to U+10FFFF are double that at 4 bytes, it’s not-so-great for English. It does happen to be better suited for Asian characters though.

There’s even UTF-32 encoding! This is a fixed-width encoding where all of the code points take four bytes — unlike the others I’ve mentioned which are dynamic in size. This can use much more storage than the other encodings, but because of its simplicity can be much faster to operate on.

Give some consideration to the alphabets you’ll need to support primarily!

Best Practices for String to Byte Array Conversion

When converting strings to byte arrays in C#, it’s important to follow best practices to ensure efficiency and reliability. In this section, I’ll discuss some key best practices that you should keep in mind when performing string to byte array conversions.

Error Handling and Validation

When working with encodings, it’s important to handle potential errors and validate your data to prevent unexpected behavior in your code. Ideally, you structure the flow of your application such that you know what kind of data you’re dealing with. If you can write code to avoid errors in the first place, this is preferred!

We don’t want to have to rely on this but sometimes it’s outside of our control — handling errors is by using try-catch blocks. By encapsulating the conversion code within a try block, you can catch any exceptions that may occur during the conversion process and handle them gracefully. If you don’t have control over the source of the input data, this is something you might need to do for safety.

Encoding Selection

C# provides several encoding options for converting strings to byte arrays, such as UTF-8, UTF-16, ASCII, and more. It’s important to select the appropriate encoding based on the specific requirements of your application. Consider factors such as character sets, compatibility with other systems, and performance implications when choosing the encoding.

// Example of encoding selection
string inputString = "Hello, World!";
byte[] encodedBytes = Encoding.UTF8.GetBytes(inputString);

Just like we saw in the previous examples, after the Encoding class we get to pick the static property holding the encoding instance. If we need to select one to pass around as a variable and parameter, you can absolutely store it in a dedicated encoding reference:

Encoding selectedEncoding = Encoding.UTF8;
SomeMethod("Hello World!", selectedEncoding);

Selecting the wrong encoding can have big consequences for your application! This is especially true if you save data with an encoding that will lose data resolution and you can’t reverse it… so put some care into this!

Now You Know How to Convert a String to Byte Array in C#!

You’re a pro now with encoding and decoding! Well, maybe not a full-on expert… but you have the basics put in front of you and some guidelines to work with. That’s a pretty good start.

Remember to select the right encoding for the situation you’re dealing with. Keep in mind that you can potentially lose data resolution when using the wrong encoding, and as a result, lose data forever!

If you found this useful and you’re looking for more learning opportunities, consider subscribing to my free weekly software engineering newsletter and check out my free videos on YouTube! Meet other like-minded software engineers and join my Discord community!

Want More Dev Leader Content?

• Follow along on this platform if you haven’t already!

• Subscribe to my free weekly software engineering and dotnet-focused newsletter. I include exclusive articles and early access to videos:
  SUBSCRIBE FOR FREE

• Looking for courses? Check out my offerings:
  VIEW COURSES

• E-Books & other resources:
  VIEW RESOURCES

• Watch hundreds of full-length videos on my YouTube channel:
  VISIT CHANNEL

• Visit my website for hundreds of articles on various software engineering topics (including code snippets):
  VISIT WEBSITE

• Check out the repository with many code examples from my articles and videos on GitHub:
  VIEW REPOSITORY

In this article, I’m going to share with you my experiences with onboarding my ASCII art generator onto an API Gateway in Zuplo. To cover all of the capabilities, I’ll need to spread this out over several articles, but this will explain how I achieved routing traffic through the gateway!

Full disclosure: Zuplo sponsored the article for my website, but I wanted to share it on additional platforms because I genuinely enjoyed working with it.

What is Zuplo?

Zuplo is an API Management platform that places an emphasis on the Developer Experience (DevEx) for building web APIs. Zuplo‘s goal is to build a platform to make it fast and straightforward to build awesome APIs. Directly from them:

We are trying to build a platform to make it fast and straightforward for developers to deliver a Stripe-level API experience to their users.

Zuplo

It’s one thing to get the logic for an API implemented — which is where historically I shine pretty well. But building out a fully operational API that you can have users and other services relying on isn’t a trivial process — especially once you consider monetizing it. You’ll need to factor in:

• Documentation

• Testing

• Deployments

• Monitoring

Nevermind all of the other things regarding access and protection like authentication and rate limiting… The list goes on. But Zuplo aims to try and get you focused on what matters (what your API needs to do) so they can handle the rest.

What is an API Gateway?

An API Gateway is a component in many modern distributed systems, particularly — but not exclusively — in microservices architectures. It acts like the bouncer at the club of your backend services, managing and directing incoming API calls from clients to various backend services. I like to think of it like “the front door” — although it does more than that.

So… What exactly does that mean?

When you have a bunch of services, each handling a specific piece of functionality (like billing, user profiles, inventory, etc.), it’s not always ideal to have everyone on the outside of your system hitting them directly. And now you might ask, “Well… Why?”, and that’s because managing all those direct connections can get messy.

Think about handling authentication, rate limiting, and data transformation for each service individually. That’s where the API Gateway comes into play. These can simplify a lot of the interactions between services as well as callers to your services on the outside. The API Gateway simplifies client interactions with your service or services — like my front door analogy — providing a single entry point for all client requests.

What Does Zuplo Offer for API Gateways?

While this article will not be covering all of these in detail (c’mon, I need to spread out the juicy details a little bit…), here are some of the core offerings from Zuplo with respect to API gateways:

• API Key Management: Zuplo allows you to add API key-based authentication to your APIs rapidly — literally in a few minutes.

• Rate Limiting and Throttling: Zuplo’s rate-limiting functionality can work great when paired with their other features, like the API keys I just mentioned. They have ready-to-go limiting based on keys or JWTs but they also allow you to customize this further in code.

• Routing and Forwarding: With Zuplo, you can handle the request right at the edge server using the code you write in Zuplo itself, you can run a lambda, or you can forward/rewrite the request!

Yes, sure, these are all things that Zuplo didn’t invent, but using these within Zuplo means you don’t have to go build them from scratch — and they make it ridiculously easy for you to use.

But what else does their platform do for you if you’re developing APIs?

• Full Policy Library: It’s actually almost ridiculous how many out-of-the-box policies are provided for what you might want to do with your API. Think of these almost like a “middleware” that you can insert inbound and outbound on your API as building blocks — which means you don’t need to go build this stuff from scratch!

• Documentation Generation: Right in the portal you’re able to configure and define documentation for your APIs, but all of the heavy lifting is done for you. Simply make your changes, customize what you want in your documentation, save and it’s automatically deployed to an easily consumable API documentation portal.

• Automatic Rapid Deployments: During my demo, I was blown away by just making changes in the portal, and pressing save, and everything is instantly deployed and live. Honestly, the API developer experience feels ridiculously smooth for these features because of how simple and quick these things become.

ASCII Art Generator Via Zuplo

In the following sections, I’ll walk you through how I went from my desktop C# ASCII art generator to an API endpoint on Zuplo that hits my server in the cloud! You can also watch the companion video where I explain how I got my ASCII art generator API setup with an API gateway:

Why an ASCII Art Generator?

In 2023 I wrote an article on ASCII art and how to create an ASCII art generator in C#. I thought this was a fun little project, but it ended up being one of the articles that still — to this very day — drives a lot of traffic to my website. Even the YouTube video, which I’ll embed right after, has a thumbnail that still ranks quite high on Google!

This project was fun to build, drove traffic to my site, and was quite self-contained with respect to the amount and complexity of code. I figured that this would be a perfect candidate to build an API for.

But back when I first started getting traction for this content, I really didn’t want to be bothered with building out all of the rate-limiting, auth, etc… These are all things I know can be done when building ASP.NET core applications, but honestly, I couldn’t be bothered to invest the time.

But Zuplo changes that for me because the reality is I don’t have to invest much time at all! I mean this candidly: When Adrian from Zuploo got on the call with me, I didn’t even realize I had a problem that Zuplo would solve until he started walking me through their offering. I realized literally while on the call that Zuplo is what could allow me to skip over the parts of API development that I truly just don’t want to work on!

Initial Challenges — Nick’s Fault!

Thanks to the code being very simple for ASCII art generation, I figured I’d just port everything over directly to Zuplo! One of the very cool features of Zuplo is that I can define a route’s logic RIGHT in Zuplo using Typescript:

It’s worth noting that just by doing that configuration, Zuplo will automatically go add the associated Typescript file for you:

So this is TOTALLY awesome — especially for Typescript folks. But here’s where my challenge started.

Because I’m dealing with images, I need a package that handle different image formats. In order to get this set up in Zuplo, which is very doable, I have to understand a little bit more about building things in Typescript. Directly from their documentation:

Additionally, you can also bundle custom modules inside of your own project. This process is does require some knowledge of node and npm, but it allows you to use any module or version of the module. To learn how to bundle your own modules, see the sample Custom Modules on Github.

Zuplo

So for those of you who work with Node and you’re familiar with all of this stuff — Lucky for you, this should be trivial! For me, the easiest thing was to pivot.

While it would be super cool to have my API running completely on Zuplo‘s edge servers, I already have machines up hosted in the cloud. It was time to turn to Azure!

Deploying A Web Service to Azure

Fortunately for me, I already had a multi-purpose API server set up in Azure that I use for several of my other projects. It’s completely plugin-based, so any time I’d like to extend functionality and add new feature sets, I just add new plugins!

In this case, it was almost just as simple as copying the example code that I had from my previous article on building an ASCII art generator in C# over to a new plugin namespace in my existing web app. One of the small steps I needed to take was putting the web API in place for the first time though!

This was an interesting opportunity though because I wasn’t writing an API in C# for end-users to hit… I was writing an API for Zuplo to hit! While I don’t want to write a crappy API right at my origin, I figured that at least Zuplo would allow me to build transforms to my API if needed.

Here’s a quick peek at what my code looks like on the server side:

using Autofac;
using Microsoft.AspNetCore.Mvc;

internal sealed class AsciiModule : Module
{
    protected override void Load(ContainerBuilder builder)
    {
        builder
            .RegisterType<AsciiArtFromUrlRequestValidator>()
            .SingleInstance();
        builder
            .RegisterType<AsciiArtGenerator>()
            .AsImplementedInterfaces()
            .SingleInstance();
        builder
            .Register(ctx =>
            {
                var app = ctx.Resolve<WebApplication>();

                var routeGroup = app.MapGroup("ascii");

                // FIXME: correct the container ordering-issue to inject properly
                var imageSourceFactory = ctx.Resolve<IImageSourceFactory>();
                var asciiArtGenerator = ctx.Resolve<IAsciiArtGenerator>();
                var asciiArtFromUrlRequestValidator = ctx.Resolve<AsciiArtFromUrlRequestValidator>();

                routeGroup.MapPost(
                    "/url",
                    async (
                        [FromBody] AsciiArtFromUrlRequest request,
                        IHttpClientFactory httpClientFactory,
                        CancellationToken cancellationToken) =>
                    {
                        if (!asciiArtFromUrlRequestValidator.Validate(request).IsValid)
                        {
                            return Results.BadRequest();
                        }

                        // FIXME: introduce further validations
                        Stream imageStream;
                        try
                        {
                            using var client = httpClientFactory.CreateClient();
                            imageStream = await client
                                .GetStreamAsync(request.ImageUrl, cancellationToken)
                                .ConfigureAwait(false);
                        }
                        catch
                        {
                            return Results.Problem();
                        }

                        using var imageSource = imageSourceFactory.CreateFromStream(imageStream);
                        var art = asciiArtGenerator.GenerateAsciiArtFromImage(
                            imageSource,
                            AsciiGenerationOptions.Default with
                            {
                                ScaleDownFactor = request.ScaleDownFactor,
                                HorizontalStretchFactor = request.HorizontalStretchFactor
                            });

                        AsciiArtResponse response = new(
                            art.Art,
                            art.Width,
                            art.Height);
                        return Results.Ok(response);
                    });

                return new RouteRegistrationDependencyMarker();
            })
            .SingleInstance();
    }
}

The code above gives us a POST route on the server that’s essentially just <server>/ascii/url, which takes a URL that my server can work with. I’d like to opt for switching over to an API where image bytes can be uploaded, but this seemed like an easy way to get started.

This isn’t going to be a full tutorial on deploying to Azure by any means but using “App Service” within Azure, I have full git-actions integration so that every time I make a commit, my application is deployed.

My Zuplo API is Alive!

Now that my own server is deployed in Azure, it’s time to rock and roll! This is where the simplicity of Zuplo really shines. Here’s the new route I added with URL rewriting:

I literally only had to press the save button (not shown in the screenshot) and within about 3 seconds the test button became live for me to use. Directly from the browser, much like using Postman, I was able to send a test URL and get back some fancy ASCII art. I’ll skip the screenshot because Zuplo isn’t optimized to try rendering ASCII art for us — I know, I know… a critical flaw!

Security Between Azure and Zuplo API Gateway

As I was putting all of this together, I said “Wait a sec! My server is still exposed to the Internet without ANY protection in front of it!”. This is realistically not a huge problem at the moment because nobody even knows the address of it. But still — I wanted to do this properly.

I reached out to Zuplo and asked “Hey, what’s your recommended way to do this?”, just in case they had more magic up their sleeves. They politely explained and mentioned that’s also covered in the example getting started documentation. And obviously, I read that ahead of time… we ALWAYS read the docs… right?

RIGHT?

After reading the documentation, I had one little change to make on my server, which was using a custom middleware for adding API authentication. By the way, if I haven’t sold you on plugin architecture before, API key authentication for my server was just another plugin:

internal sealed class ApiKeyModule : Module
{
    protected override void Load(ContainerBuilder builder)
    {
        builder
            .Register(ctx =>
            {
                var app = ctx.Resolve<WebApplication>();
                var config = ctx.Resolve<IConfiguration>();

                const string ApiKeyConfigKey = "<APP_CONFIG_KEY_HERE>";
                Lazy<string?> lazyApiKey = new(() => config.GetValue<string>(ApiKeyConfigKey));

                app.Use(async (context, next) =>
                {
                    const string ApiKeyHeader = "<HEADER_KEY_GOES_HERE>";
                    if (!context.Request.Headers.TryGetValue(ApiKeyHeader, out var apiKeyVal))
                    {
                        context.Response.StatusCode = 401;
                        await context.Response.WriteAsync("Api Key not found.");
                    }

                    var apiKey = lazyApiKey.Value;
                    if (!string.Equals(apiKey, apiKeyVal, StringComparison.Ordinal))
                    {
                        context.Response.StatusCode = 401;
                        await context.Response.WriteAsync("Invalid API Key.");
                    }

                    await next(context);
                });

                return new PostAppRegistrationDependencyMarker();
            })
            .SingleInstance();
    }
}

Now one more super quick change to Zuplo to add a policy to add my configured API key that I have on my server, and we’re done:

What’s Next for API Gateways in Zuplo?

At this point, I have a public API through Zuplo that can get hit, uses an API key with my own server, forwards that request, and gets the response. It’s a full end-to-end integration which I would have loved to do right within Zuplo — but my Typescript skills were mocking me. That will certainly be an exercise for the future because I think it would be awesome to have this one truly at the edge node.

But before I can make this API public, I still need a few more things… And I never actually accomplished them yet:

• API Documentation

• Rate limiting

• Authentication

• Monetization!

The good news is that since I have my API integrated with Zuplo now, a lot of what’s left is almost all drag-and-drop in their portal! I don’t suspect I’ll have to code anything inside of my own server at this point.

Wrapping Up API Gateways in Zuplo

Overall, I thought this was an awesome platform to work with. Getting API Gateways in Zuplo setup is simple and quick — it’s hard to argue with those two things. But if you consider people like me who don’t want to go hand-roll this kind of stuff per service they create, the fact that they’ve integrated so many building blocks makes this dreamy. There were policies in the catalog that made me think “Oh crap! I didn’t even consider that!”.

I’m looking forward to continuing to build this API out in Zuplo and getting it to a point where I can monetize it! So keep your eyes peeled — because you’ll soon have an ASCII art API you can integrate with. While yes, this post is sponsored by Zuplo , I can say without a doubt their platform greatly simplifies a lot of the pain points I never enjoy dealing with when I develop.

Want More Dev Leader Content?

• Follow along on this platform if you haven’t already!

• Subscribe to my free weekly software engineering and dotnet-focused newsletter. I include exclusive articles and early access to videos:
  SUBSCRIBE FOR FREE

• Looking for courses? Check out my offerings:
  VIEW COURSES

• E-Books & other resources:
  VIEW RESOURCES

• Watch hundreds of full-length videos on my YouTube channel:
  VISIT CHANNEL

• Visit my website for hundreds of articles on various software engineering topics (including code snippets):
  VISIT WEBSITE

• Check out the repository with many code examples from my articles and videos on GitHub:
  VIEW REPOSITORY

And that means YOU get some free code and a reference guide to go along with it!

What is Middleware in ASP.NET Core?

Middleware in ASP.NET Core is code that you can add into an application’s pipeline to handle requests and responses. Each of these components can:

• Choose whether to pass the request to the next component in the pipeline

• Can perform work before and after the next component in the pipeline.

When building an ASP.NET Core application, middleware can be used to implement functionality such as authentication, error handling, logging, and serving static files. The list goes on, and you can even implement your own custom middleware. If you’d like more information on middleware to get started, you can check out this article that I’ve written:

• Custom Middleware in ASP.NET Core – How to Harness the Power!

For our use case here, we’ll be looking at adding our own custom middleware to an ASP.NET Core application. Given that we want to do some type of authentication with an API key, we should be able to create middleware that STOPS processing if the key is invalid or CONTINUE processing if the key is valid. Should be simple enough, right? Let’s continue on and see!

API Key Authentication Middleware Example Code

Now that you understand what middleware in ASP.NET core is, let’s look at an example. For my application, I wanted to handle the API key from the request header. Of course, this could be done in different ways, like having a query parameter for example, but the header was what I decided to go with.

Here’s the example API key authentication middleware in this code snippet:

public async Task MyMiddleware(
    HttpContext context,
    RequestDelegate next)
{
    // if you wanted it as a query parameter, you'd
    // want to consider changing this part of the code!
    const string ApiKeyHeader = "<YOUR_HEADER_KEY_HERE>";
    if (!context.Request.Headers.TryGetValue(ApiKeyHeader, out var apiKeyVal))
    {
        context.Response.StatusCode = 401;
        await context.Response.WriteAsync("Api Key not found.");
        return;
    }

    const TheRealApiKey = "<YOUR_SECRET_API_KEY_HERE>";
    if (!string.Equals(TheRealApiKey, apiKeyVal, StringComparison.Ordinal))
    {
        context.Response.StatusCode = 401;
        await context.Response.WriteAsync("Invalid API Key.");
        return;
    }

    await next(context);
}

The code above is very much representative of the chain of responsibility design pattern! Our middleware handler can take action, and then is able to call into the next delegate using the context that was passed in — or it can terminate the sequence by writing a response back and leaving the method without calling the next handler. But if you’re wondering where we hook this up, then check this code snippet:

// "app" here is the WebApplication instance after
// being built by the web application builder
app.Use(MyMiddleware);

Odds are you do NOT want to have your API key right in your code — in fact, I would say “PLEASE DO NOT DO THIS!” so that you don’t accidentally commit a secret API key into your source control. A way that we can work around this is by using environment variables and the app configuration! So in the following code example, you can see a string value being looked up in the application’s configuration:

// "app" here is the WebApplication instance after
// being built by the web application builder
var config = app.Configuration
var secretApiKey = config.GetValue<string>("<CONFIG_KEY_NAME>");

Now instead of comparing against a hard-coded API key directly in your code, you can read it from a configuration instance, which can be populated by environment variables!

Using This With Plugin Architecture in C#

It’s no secret that I like using plugin architectures when I’m developing software — but this might be your first time reading some of my content. So spoiler alert: I love using plugins when designing software systems.

In the ASP.NET Core application that I wanted to add my API key authentication middleware to, I have a very simple loading scheme that allows dependencies to “hook” into the web application building process. This is accomplished by a couple of basic steps:

• I use Autofac and assembly scanning to look for DLLs with Autofac modules to load in at startup time

• These DLLs become plugins, so by definition any plugin can then use the dependency container builder to register their own dependencies

• Part of that registration process means they can ask the container for the web application instance that was built

• Once they have that web application instance, they are able to hook up their middleware to it.

This is a very simple/naive way to do this because there’s no ordering or control on the middleware. If certain middleware MUST be registered before/after other middleware, there’s no opportunity to say so — You just buckle up and hope for the best. However, that’s okay for now because my middleware needs are EXTREMELY limited currently. I will create an ordering scheme for this if/when necessary.

So what does my plugin code look like? Pretty much what we saw earlier, except inside of an Autofac module:

internal sealed class ApiKeyModule : Module
{
    protected override void Load(ContainerBuilder builder)
    {
        builder
            .Register(ctx =>
            {
                var app = ctx.Resolve<WebApplication>();
                var config = ctx.Resolve<IConfiguration>();

                const string ApiKeyConfigKey = "API_CONFIG_KEY_NAME";
                Lazy<string?> lazyApiKey = new(() => config.GetValue<string>(ApiKeyConfigKey));

                app.Use(async (context, next) =>
                {
                    const string ApiKeyHeader = "HEADER_KEY_NAME";
                    if (!context.Request.Headers.TryGetValue(
                        ApiKeyHeader,
                        out var apiKeyVal))
                    {
                        context.Response.StatusCode = 401;
                        await context.Response.WriteAsync("Api Key not found.");
                        return;
                    }

                    var apiKey = lazyApiKey.Value;
                    if (!string.Equals(apiKey, apiKeyVal, StringComparison.Ordinal))
                    {
                        context.Response.StatusCode = 401;
                        await context.Response.WriteAsync("Invalid API Key.");
                        return;
                    }

                    await next(context);
                });

                // this is used to help control the ordering of dependencies
                // so the application won't start until all of these
                // have been resolved!
                return new PostAppRegistrationDependencyMarker();
            })
            .SingleInstance();
    }
}

If you’re wondering what the benefit is: I never had to touch any other code in my project and I instantly added API authentication to every single route. This code is currently in the main assembly, but I could have added it to a new project, built the DLL, and dropped it into the running directory to get this behavior activated.

That’s the power of building with plugins!

Wrapping Up API Key Authentication Middleware

Overall, adding API key authentication middleware in ASP.NET Core applications is quite simple! The middleware can be added directly onto the application instance and you can decide how you’d like to load your secret API key to compare against. By sprinkling in a little bit of C# plugin architecture like I prefer to use in many of my projects, it’s a breeze to extend the functionality of your ASP.NET Core app!

If you found this useful and you’re looking for more learning opportunities, consider subscribing to my free weekly software engineering newsletter and check out my free videos on YouTube! Meet other like-minded software engineers and join my Discord community!

Want More Dev Leader Content?

• Follow along on this platform if you haven’t already!

• Subscribe to my free weekly software engineering and dotnet-focused newsletter. I include exclusive articles and early access to videos:
  SUBSCRIBE FOR FREE

• Looking for courses? Check out my offerings:
  VIEW COURSES

• E-Books & other resources:
  VIEW RESOURCES

• Watch hundreds of full-length videos on my YouTube channel:
  VISIT CHANNEL

• Visit my website for hundreds of articles on various software engineering topics (including code snippets):
  VISIT WEBSITE

• Check out the repository with many code examples from my articles and videos on GitHub:
  VIEW REPOSITORY

If you enjoy this kind of content, I often write about it in my weekly newsletter. You can subscribe to it for free:

1 – Keep Building

Keep building things. It doesn’t matter if they’re not million-dollar product ideas. Build things to learn about how they work.

The goal when we’re building things, especially early in our software engineering journeys, is not to get-rich-quick. The goal is to practice and learn.

There’s no shortcut to mastery except for understanding sooner that there’s no shortcut. We need to practice — so build software.

2 – Reinvent The Wheel

We’re always told to not reinvent the wheel. There’s no point doing it if someone else has already done it.

But this isn’t always good advice.

Reinventing the wheel is one of the best ways to understand how something works and the complexity behind it. It might not be the best thing to chase in a production environment with paying customers, but it’s great for learning.

If you’re ever curious about how things work or interested in the complexities of a system or technology — try building it yourself. You’re almost guaranteed to learn something about what you’re diving into. I’d be shocked if you didn’t!

3 – Learn In Public

Document your journey so others can learn alongside you. This can help reinforce learning in so many ways because you need to find ways to explain the concepts that you think you’re now understanding.

However, don’t masquerade as an expert. Be humble and acknowledge that you’re new and learning. Others will be more willing to help.

Remember that everyone has different opinions. Some people are more loud but it doesn’t make them more correct. In fact, the louder people unwilling to listen to other perspectives are more often than not going to be less helpful. So don’t be discouraged.

If people correct your mistakes, this is a great chance for you to take lessons learned and improve!

4 – We Build Software In Teams

In the large majority of cases, software is built in teams. This means that you need to focus on communication skills, collaboration skills, and ALL of the other skills that aren’t just technical.

When it comes to technical direction, you need to consider that it’s not just your choices.

This is a good thing — because the different backgrounds, experiences, and perspectives will allow you to build better software as a group.

5 – Composition > Inheritance

Inheritance gets pushed a LOT when teaching programming but if you gravitate towards using composition early then you’ll “shortcut” a few years of really crappy code.

Seriously. I’m guilty of writing mountains of code with ridiculously long inheritance hierarchies. I can’t blame this entirely on WinForms and the Controls paradigm that was used… I should have taken some responsibility!

I’d spend a good portion of my early career rewriting a lot of overly complex inheritance code because it became too complex.

6 – Don’t Fear Learning

Don’t be afraid to learn new things. Building expertise can feel great, but don’t let it make you feel so safe that new things feel scary.

You’re going to suck at new things but it’s very temporary. You’ll prove to yourself repeatedly that you eventually get working knowledge and feel very comfortable.

In my career, my best growth opportunities were when I was forced into something new and uncomfortable. Every time I came out on top.

Discomfort led to incredible learning experiences.

7 – Own Your Career Development

Nobody is as interested in your career progression as you are. Great managers will indeed help encourage you and give you opportunities to move things along.

But we can’t just sit back and wait for this. We won’t always have amazing managers.

The sooner you realize that being passive is not a good strategy for progression, the sooner you can take action.

8 – Remember To Have Fun

You’re in this for the long haul, spending many hours of your life building software. You better enjoy it.

Not every day is going to be easy. Not every day will be interesting. Not every day will exciting.

But overall, you need to find ways to enjoy what you’re doing. It will help you learn. It will help you be engaged. It will help you be motivated to push through interesting challenges.

Software engineering is very mentally demanding and it’s often hard to find a good work-life balance… So keep this one in mind throughout your career.

What would you add or change? If you found this insightful and you’re looking for more learning opportunities, consider subscribing to my free weekly software engineering newsletter and check out my free videos on YouTube! Meet other like-minded software engineers and join my Discord community!

Want More Dev Leader Content?

• Follow along on this platform if you haven’t already!

• Subscribe to my free weekly software engineering and dotnet-focused newsletter. I include exclusive articles and early access to videos:
  SUBSCRIBE FOR FREE

• Looking for courses? Check out my offerings:
  VIEW COURSES

• E-Books & other resources:
  VIEW RESOURCES

• Watch hundreds of full-length videos on my YouTube channel:
  VISIT CHANNEL

• Visit my website for hundreds of articles on various software engineering topics (including code snippets):
  VISIT WEBSITE

• Check out the repository with many code examples from my articles and videos on GitHub:
  VIEW REPOSITORY

In this article, I’ll explain my error so you can try to avoid this for yourself… and of course, I’ll provide new benchmarks and an update to the benchmarking code using BenchmarkDotNet.

The Invalid C# Regular Expression Benchmarks

In the previous article I wrote about C# regular expression benchmarks, I had results that illustrated enormous performance gains if you were incorrectly using some of the available C# regex methods. The benchmark results clearly indicated that the cost of creating a new regex object in C# was expensive, and even more expensive if you had the compile flag. So if you were doing this each time you wanted to match, you were paying an unfortunately high penalty.

You can watch the video walking through these benchmarks here to get a better idea, keeping in mind that the results we’re about to discuss are the correct ones:

There was a great YouTube comment that came up pretty shortly after the video was released, and here’s what the viewer had to say:

That meant I had to go back to the drawing board to investigate!

Being Lazy Like C# Iterators…

As the viewer pointed out… it looks like MatchCollection that comes back from doing a regex match is lazily evaluated. That might be confusing if you haven’t heard of this concept before, but this is all much like using iterators in C#, which I have talked about extensively. If you want a bit of a crash course on the idea behind iterators in C#, you can check out this video for a walkthrough of my experiences:

Long story short: It looks like a line of code executes a method, but you’re simply just assigning a function pointer to a variable. The result is that instead of a method taking some amount of time to run, you instead have it execute nearly instantaneously.

But is the MatchCollection actually a C# iterator, or is it something else?

Revisiting The C# Regex Benchmark Code

Let’s consider the following code, which is one of the simple benchmarks from the previous article:

Regex regex = new(RegexPattern!, RegexOptions.Compiled);
return regex.Matches(_sourceText!);

What we’re returning in that benchmark method is actually what’s called a MatchCollection. We could instead write that code as follows:

Regex regex = new(RegexPattern!, RegexOptions.Compiled);
MatchCollection matches = regex.Matches(_sourceText!);
return matches;

The line in the middle of the code example directly above looks like it’s evaluating all of the matches, but indeed it returns nearly instantly. That’s definitely not what we wanted to measure! Instead, I was just measuring the cost of creating a MatchCollection instance vs creating an entire C# Regex object instance plus a MatchCollection instance. This explains why of course the two benchmarks that created instances were absolutely guaranteed to be slower — they did the same thing when it came to creating a MatchCollection instance, but they had their own associated overhead for regular expression creation.

What’s Happening With MatchCollection?

Well, it turns out that MatchCollection is not quite an iterator, but it certainly is lazily evaluated. If you keep jumping to the definition and go deeper into the code for MatchCollection, you’ll see the following:

private void EnsureInitialized()
{
    if (!_done)
    {
        GetMatch(int.MaxValue);
    }
}

This is a method called in many spots within the MatchCollection class, and basically any time someone wants to access information about the matches, we eventually need to get into the GetMatch method. That method looks as follows:

private Match? GetMatch(int i)
{
    Debug.Assert(i >= 0, "i cannot be negative.");

    if (_matches.Count > i)
    {
        return _matches[i];
    }

    if (_done)
    {
        return null;
    }

    Match match;
    do
    {
        match = _regex.RunSingleMatch(
            RegexRunnerMode.FullMatchRequired,
            _prevlen,
            _input,
            0,
            _input.Length,
            _startat)!;
        if (!match.Success)
        {
            _done = true;
            return null;
        }

        _matches.Add(match);
        _prevlen = match.Length;
        _startat = match._textpos;
    } while (_matches.Count <= i);

    return match;
}

If you step through this code, you’ll notice that there’s state kept for how far along in the matches a caller is looking for. That means if this instance has not yet been evaluated that far along, it will then go attempt to evaluate that far based on the requested index. Looks pretty lazy to me! But if that wasn’t a giveaway… Look how the constructor doesn’t even take a collection of matches at the time of creation!

internal MatchCollection(Regex regex, string input, int startat)
{
    if ((uint)startat > (uint)input.Length)
    {
        ThrowHelper.ThrowArgumentOutOfRangeException(
            ExceptionArgument.startat,
            ExceptionResource.BeginIndexNotNegative);
    }

    _regex = regex;
    _input = input;
    _startat = startat;
    _prevlen = -1;
    _matches = new List<Match>();
    _done = false;
}

Please keep in mind that this is what Visual Studio is showing me, and if you try checking the source at a later point it may be different in the dotnet code.

You can also follow along with this video here:

The New Code for C# Regular Expression Benchmarks

Let’s jump right into the new BenchmarkDotNet code for these regular expression scenarios, which will look VERY similar to before:

using BenchmarkDotNet.Attributes;
using BenchmarkDotNet.Running;

using System.Reflection;
using System.Text.RegularExpressions;

BenchmarkRunner.Run(
    Assembly.GetExecutingAssembly(), 
    args: args);

[MemoryDiagnoser]
[MediumRunJob]
public partial class RegexBenchmarks
{
    private const string RegexPattern = @"\b\w*(ing|ed)\b";

    private string? _sourceText;
    private Regex? _regex;
    private Regex? _regexCompiled;
    private Regex? _generatedRegex;
    private Regex? _generatedRegexCompiled;

    [GeneratedRegex(RegexPattern, RegexOptions.None, "en-US")]
    private static partial Regex GetGeneratedRegex();

    [GeneratedRegex(RegexPattern, RegexOptions.Compiled, "en-US")]
    private static partial Regex GetGeneratedRegexCompiled();

    [Params("pg73346.txt")]
    public string? SourceFileName { get; set; }

    [GlobalSetup]
    public void Setup()
    {
        _sourceText = File.ReadAllText(SourceFileName!);

        _regex = new(RegexPattern);
        _regexCompiled = new(RegexPattern, RegexOptions.Compiled);
        _generatedRegex = GetGeneratedRegex();
        _generatedRegexCompiled = GetGeneratedRegexCompiled();
    }

    [Benchmark(Baseline = true)]
    public int Static()
    {
        return Regex.Matches(_sourceText!, RegexPattern!).Count;
    }

    [Benchmark]
    public int New()
    {
        Regex regex = new(RegexPattern!);
        return regex.Matches(_sourceText!).Count;
    }

    [Benchmark]
    public int New_Compiled()
    {
        Regex regex = new(RegexPattern!, RegexOptions.Compiled);
        return regex.Matches(_sourceText!).Count;
    }

    [Benchmark]
    public int Cached()
    {
        return _regex!.Matches(_sourceText!).Count;
    }

    [Benchmark]
    public int Cached_Compiled()
    {
        return _regexCompiled!.Matches(_sourceText!).Count;
    }

    [Benchmark]
    public int Generated()
    {
        return GetGeneratedRegex().Matches(_sourceText!).Count;
    }

    [Benchmark]
    public int Generated_Cached()
    {
        return _generatedRegex!.Matches(_sourceText!).Count;
    }

    [Benchmark]
    public int Generated_Compiled()
    {
        return GetGeneratedRegexCompiled().Matches(_sourceText!).Count;
    }

    [Benchmark]
    public int Generated_Cached_Compiled()
    {
        return _generatedRegexCompiled!.Matches(_sourceText!).Count;
    }
}

If you compare these benchmark methods to the previous article, you’ll notice they are very close with a very subtle difference: I’m returning an integer count instead of the MatchCollection. If you consider this and what I pointed out in the code earlier, Count is one of the properties on MatchCollection that will eventually try to evaluate the matches under the hood — as in, it will force the lazy behavior to get evaluated.

We can see that by factoring in this code snippet below:

/// <summary>
/// Returns the number of captures.
/// </summary>
public int Count
{
    get
    {
        EnsureInitialized();
        return _matches.Count;
    }
}

The New Results of C# Regular Expression Benchmarks

Now that I’ve come clean and admitted that I totally screwed up on my benchmarks AND provided you the updated code, let’s redo this analysis. Here are the newly run benchmarks:

Now here are some interesting things to make note of:

• The static method call is indeed the worst of all the options. While it’s nearly identical, creating a new regex is only a tiny bit faster as these benchmark results show. Under the hood, the static method call does try to get or add the regex to a cache, which seems to be a static collection of regular expressions that have been created. MORE ON THIS SHORTLY

• It looks like now in these benchmarks the overhead of compiling the regex is now WORTH doing, even if you’re going to do it each time you go to find matches. About a 56% performance boost! We need to keep in mind the pattern I’m using, the contents of data that’s being tested, and the overall length of that data as well.

• Simply caching the regex in a field shows very minimal performance benefits, if not just a rounding error, for this setup. Again, this could be largely due to the size of the data and the pattern being used, and perhaps a very short set of data to scan would make caching proportionally more advantageous.

• Now we get into the magic territory where we can see caching a compiled regex gives us performance that is 310% of the baseline. Not having to recompile is very helpful here!

• As predicted, like in the original article, all of the generated regexes are on par with each other, and in this test setup perform exactly on par with the compiled cached regex.

But Wait! There’s Caching!

I wanted to be even more careful before publishing this follow-up article on C# regular expression benchmarks because of the first slip up I had. I recalled that the regex class has a RegexCache internal to the dotnet code that is running — and since we’re using the same pattern over and over… Are we caching things behind the scenes?

It turns out, we can change the cache size to zero by doing the following:

Regex.CacheSize = 0;

If I add this line of code to the beginning of the benchmark runner, I can be assured that the caching is turned off. But just to be sure, I added this debug watch in Visual Studio after creating a regex just to sanity check:

typeof(RegexCache)
    .GetField("s_cacheList", BindingFlags.Static | BindingFlags.NonPublic)
    .GetValue(null)

The result of this was seeing an empty cache, which is exactly what I was hoping for. A quick note is that RegexCache is internal, and I wasn’t sure the best way to get reflection to work in code to access this (i.e. not sure which assembly to go look at), but this does resolve properly in the debug watch list! But now you’re probably interested in the results:

Interestingly — there’s really no difference here. I suspect this is largely because the text we’re scanning through is large enough that the time it takes to evaluate regex matches mostly dwarfs the time it takes to create the regex objects. This is exactly what was not shown in the original article where the time to evaluate was basically zero because we never evaluated the matches.

Wrapping Up C# Regular Expression Benchmarks

Okay, now it’s time for some lessons learned…

1. It’s okay to make mistakes. We’re all human.

2. Mistakes are a great way to take ownership and show others that we can grow from messing up!

3. Failing is one of the best ways to learn. I had absolutely no idea MatchCollection was lazy after probably 10+ years of using Regex in C#.

At the end of the day, these new C# regular expression benchmarks are still very helpful in understanding just how big of an impact compiling your regex can have! Ideally, you don’t want to be recreating new regex instances, especially with the compile flag… but the performance of compiled regexes is awesome.

If you found this useful and you’re looking for more learning opportunities, consider subscribing to my free weekly software engineering newsletter and check out my free videos on YouTube! Meet other like-minded software engineers and join my Discord community!

Want More Dev Leader Content?

• Follow along on this platform if you haven’t already!

• Subscribe to my free weekly software engineering and dotnet-focused newsletter. I include exclusive articles and early access to videos:
  SUBSCRIBE FOR FREE

• Looking for courses? Check out my offerings:
  VIEW COURSES

• E-Books & other resources:
  VIEW RESOURCES

• Watch hundreds of full-length videos on my YouTube channel:
  VISIT CHANNEL

• Visit my website for hundreds of articles on various software engineering topics (including code snippets):
  VISIT WEBSITE

• Check out the repository with many code examples from my articles and videos on GitHub:
  VIEW REPOSITORY

When we have options that look the same, I like remaining curious and understanding what’s actually different. This turned out to be a fun exercise and I hope you have some learnings to take away just like I did!

PLEASE NOTE:

There was an error in the benchmarks that I created because of an assumption that was invalid. The contents of this article can still be very valuable, but there is an update to the benchmark code and an accurate analysis in this follow-up article:
https://www.devleader.ca/2024/04/12/csharp-regular-expression-benchmarks-how-to-avoid-my-mistakes/

What is a Regular Expression?

Regular expressions, often referred to as regex, are powerful tools used for pattern matching in text. They allow you to define a search pattern that can be used to find, replace, or manipulate specific parts of a string. Regular expressions provide a concise and flexible way to search for and identify specific patterns within text data.

I have used regular expressions for many different things in my career such as:

• Pattern matching on user input

• Scraping data from the web

• Parsing data sources like logs or other files

• Digital forensics data recovery

• … and many more uses!

Regular expressions can be used for all sorts of advanced pattern matching. But if you want to get started you can check out these articles:

• Some simple examples using C# regular expressions

• C# Regex options

Why Benchmark Regex Performance in C#?

Aside from when I am trying to profile and optimize my applications and services, I like benchmarking things when I am curious. This happens especially when I find there are seemingly multiple ways to do the same thing — it makes me wonder TRULY what the differences are aside form just syntax and usability. Recently with collection initializers, I was completely blown away by the performance differences, so it’s always a good reminder to be curious.

Regular expressions in C# have several different flavors:

• Static method call

• Compiled flag or not

• Source generators

Now, the compiled flag is supposed to give us a performance boost but what’s the overhead of using just the static method call since it makes things really convenient to call in code? And what the heck are these (relatively) new source generators for regular expressions in C#? Microsoft had some REALLY awesome documentation on compiled regular expressions and source generation — and I never would have stumbled upon this if I wasn’t curious to benchmark.

While we won’t be comparing all of the regex methods we have access to, I did want to see the performance difference for getting all matches in a body of text. Considering the scenarios listed above, I was curious to see which would pull forward given they all seem roughly the same on the surface.

Setting Up C# Regex Performance Benchmarks

I know you’re eager to jump STRAIGHT to the details, and while nothing is stopping you from scrolling to the bottom I’m hopeful you’ll pause in this section to understand the benchmarks first. When I post benchmarking investigations, my ultimate goal is not to persuade you to code differently, but rather to be curious about what you’re coding. I think we’ll see some obvious things to avoid in these benchmarks — but still, being curious is the goal.

I’ll be working with BenchmarkDotNet as usual for these benchmarks. If you’re interested in learning more about how to run your own benchmarks I have plenty of BenchmarkDotNet articles you can check out.

The Test Data For Benchmarking

While we’re not interested in absolute performance here — and you might be if you’re profiling and benchmarking your own application — we are interested in relative performance between our various Regex options. Aside from the options we have to use, some other considerations:

• The Regex pattern that we use could potentially influence how each mechanism performs

• The source of data we try to match could have some sort of influence on the results

I call these things out because they are uncertain to me. The source data I feel shouldn’t be TOO big of an issue — but maybe different heuristics of matching don’t allow compiled or source-generated regular expressions to shine. Maybe the Regex pattern I’ve selected doesn’t allow compiled or source-generated regular expressions to have an advantage. Or maybe it does — and I should be able to call this out.

The point is that there are some variables that may influence results and I don’t fully understand how. But this is me being transparent, and if you know better feel free to share your insights!

I figured to make this as “fair” as possible, I would look for some patterns in real text: words that end in “ing” or in “ed”. To find some real text, I am using the data from Project Gutenberg — Specifically, this E-Book. It’s 2200+ lines of English text so there are plenty of matches on words for our pattern.

The C# Regex Benchmark Code

There’s nothing super unique about these benchmarks compared to others I normally create. However, I’ll list out some points of interest so that you can pick them out in the code:

• I’m using [Params] to load the source file in case you want to try these benchmarks across different datasets

• The source data is read in during the global setup

• I need to cache some Regex instances for some of the benchmarks, which is done in the global setup

You can find the benchmark code here on GitHub and in the code below:

using BenchmarkDotNet.Attributes;
using BenchmarkDotNet.Running;

using System.Reflection;
using System.Text.RegularExpressions;

BenchmarkRunner.Run(
    Assembly.GetExecutingAssembly(), 
    args: args);

[MemoryDiagnoser]
[MediumRunJob]
public partial class RegexBenchmarks
{
    private const string RegexPattern = @"\b\w*(ing|ed)\b";

    private string? _sourceText;
    private Regex? _regex;
    private Regex? _regexCompiled;
    private Regex? _generatedRegex;
    private Regex? _generatedRegexCompiled;

    [GeneratedRegex(RegexPattern, RegexOptions.None, "en-US")]
    private static partial Regex GetGeneratedRegex();

    [GeneratedRegex(RegexPattern, RegexOptions.Compiled, "en-US")]
    private static partial Regex GetGeneratedRegexCompiled();

    [Params("pg73346.txt")]
    public string? SourceFileName { get; set; }

    [GlobalSetup]
    public void Setup()
    {
        _sourceText = File.ReadAllText(SourceFileName!);

        _regex = new(RegexPattern);
        _regexCompiled = new(RegexPattern, RegexOptions.Compiled);
        _generatedRegex = GetGeneratedRegex();
        _generatedRegexCompiled = GetGeneratedRegexCompiled();
    }

    [Benchmark(Baseline = true)]
    public MatchCollection Static()
    {
        return Regex.Matches(_sourceText!, RegexPattern!);
    }

    [Benchmark]
    public MatchCollection New()
    {
        Regex regex = new(RegexPattern!);
        return regex.Matches(_sourceText!);
    }

    [Benchmark]
    public MatchCollection New_Compiled()
    {
        Regex regex = new(RegexPattern!, RegexOptions.Compiled);
        return regex.Matches(_sourceText!);
    }

    [Benchmark]
    public MatchCollection Cached()
    {
        return _regex!.Matches(_sourceText!);
    }

    [Benchmark]
    public MatchCollection Cached_Compiled()
    {
        return _regexCompiled!.Matches(_sourceText!);
    }

    [Benchmark]
    public MatchCollection Generated()
    {
        return GetGeneratedRegex().Matches(_sourceText!);
    }

    [Benchmark]
    public MatchCollection Generated_Cached()
    {
        return _generatedRegex!.Matches(_sourceText!);
    }

    [Benchmark]
    public MatchCollection Generated_Compiled()
    {
        return GetGeneratedRegexCompiled().Matches(_sourceText!);
    }

    [Benchmark]
    public MatchCollection Generated_Cached_Compiled()
    {
        return _generatedRegexCompiled!.Matches(_sourceText!);
    }
}

For our benchmarks, we’ll treat the static method on the Regex class as the baseline — just so we have something to anchor to when looking at the performance results.

C# Regex Performance Results

With the BenchmarkDotNet code out of the way, let’s see the results:

From above we can see that creating a new Regex instance every time you want to perform a match is 100x slower than the static method. This is incredible — you should NOT do this if performance is important to you! But it gets worse… If you do this AND provide the compile flag, it’s almost 1000x as bad, 10x worse than newing it up every time. These are two things you should avoid doing.

We can see with the cached variations that follow that we can effectively invert the situation, giving us a slight boost over the static method. While these runtimes are very fast, it looks like in these situations it’s nearly 30% faster. But temper your expectations as I’m not convinced this scales with different data sets and different patterns!

The source-generated C# regular expressions are also much faster than the static method — but seem roughly on par with the two prior benchmarks. While the source-generated regular expressions do cache and calling the source-generated method should be no overhead, there are two benchmark variations that suggest it’s marginally faster to keep your own cache. These could simply be outliers though given how close the results are.

You can check out the video for a full walk-through on these C# regex benchmarks:

Wrapping Up C# Regex Performance

The takeaways for optimizing C# Regex performance: Stop declaring regular expressions in C# right before you go to use them! And even worse, stop declaring them with the compiled flag if you’re declaring them right before using them! These two things will crush your performance.

Otherwise, it seems like the Regex class with static method across the board is pretty safe, but you get the most benefit out of compiling and caching your regex. And according to Microsoft, can be improved even further with the C# Regex source generators in many situations.

If you found this useful and you’re looking for more learning opportunities, consider subscribing to my free weekly software engineering newsletter and check out my free videos on YouTube! Meet other like-minded software engineers and join my Discord community!

Want More Dev Leader Content?

• Follow along on this platform if you haven’t already!

• Subscribe to my free weekly software engineering and dotnet-focused newsletter. I include exclusive articles and early access to videos:
  SUBSCRIBE FOR FREE

• Looking for courses? Check out my offerings:
  VIEW COURSES

• E-Books & other resources:
  VIEW RESOURCES

• Watch hundreds of full-length videos on my YouTube channel:
  VISIT CHANNEL

• Visit my website for hundreds of articles on various software engineering topics (including code snippets):
  VISIT WEBSITE

• Check out the repository with many code examples from my articles and videos on GitHub:
  VIEW REPOSITORY

What is Composition in Object-Oriented Programming?

In object-oriented programming, composition refers to the concept of building complex functionality by combining smaller objects together. When we talk about composition, we mean that objects can be composed of other objects, known as “components” or “parts”, to achieve a desired behavior or functionality. I like saying that composition represents an “is made up of” relationship, whereas when we talk about inheritance we mean that things have an “is a” relationship.

Let’s see if we can get this idea to be a little bit more clear with an example. We’ll stick to something that isn’t C# specific or even code-related so that you can rationalize the concept of an “is made up of” relationship.

Let’s consider a music band as a combination of musicians:

• a guitarist

• a drummer

• a singer

Each member plays their own instrument or role and there is no relationship between each of these members aside from being in the same band. When we describe the band itself, we would say the band “has-a” guitarist, “has-a” drummer, and “has-a” singer. We could also then say that the band “is made up of” these musicians!

This illustrates composition, where we assemble different elements (musicians) each with unique capabilities, to create a complete unit (the band) that performs music together. Each member contributes their part to the overall performance, showcasing how individual components are combined to achieve a larger, coordinated function. I might even slip in another example here where we say the complexity of the musicians working together is “encapsulated” when are on the outside of the band, listening to the music.

How Composition Works in C#

So, how does composition work in C#, and how can you leverage this technique in your software development? Hint: it doesn’t start with inheriting from a base class!

To create composition relationships between objects in C#, we can use classes and interfaces. A class represents a blueprint for creating objects, while an interface defines a contract that a class must follow. By using composition, we can bring together various classes and interfaces to form a cohesive and flexible system.

It’s also important to note that we can compose objects of other objects and NOT use interfaces at all, but I thought excluding the usage of interfaces entirely might be misleading. So you can use interfaces as the things you will compose other objects of, but you do not need to for it to be a composition relationship.

Examples of Composition in C#

In object-oriented programming, composition is a powerful concept that allows us to model relationships between real-world entities. By leveraging composition, we can create complex systems by combining smaller, more manageable components. Let’s explore some examples of composition in different scenarios using C# code snippets.

Music Player Composition Example in C#

Let’s see composition in action! Consider this simple example of a music player application. We might have a MusicPlayer class that represents the core functionality of the application, such as playing audio files. However, the music player also needs additional capabilities, such as a user interface and audio codecs. That is, we can’t have something that plays music without it being made of these two dependencies! Here’s some example code:

public class MusicPlayer
{
    private readonly IUserInterface _userInterface;
    private readonly IAudioCodec _audioCodec;

    public MusicPlayer(
        IUserInterface userInterface,
        IAudioCodec audioCodec)
    {
        _userInterface = userInterface;
        _audioCodec = audioCodec;
    }

    // Do stuff using the user interface
    // and the audio codec

    // Rest of the implementation...
}

In the example above, the MusicPlayer class depends on an IUserInterface and an IAudioCodec interface. Instead of implementing these dependencies directly in the MusicPlayer class, we use composition to inject them as constructor parameters. This allows us to easily swap out different implementations of the user interface and audio codecs, providing flexibility and extensibility to our music player application.

Now, let’s see how we can compose the music player with concrete implementations of the interfaces:

public class ConsoleUserInterface : IUserInterface
{
    // Implementation of IUserInterface...
}

public class Mp3AudioCodec : IAudioCodec
{
    // Implementation of IAudioCodec...
}

// Usage
var userInterface = new ConsoleUserInterface();
var audioCodec = new Mp3AudioCodec();
var musicPlayer = new MusicPlayer(
    userInterface,
    audioCodec);

In this example, we have two classes, ConsoleUserInterface and Mp3AudioCodec, that implement the IUserInterface and IAudioCodec interfaces, respectively. We then create instances of these concrete classes and pass them into the MusicPlayer constructor to compose the music player object.

By using composition, we have decoupled the specific implementations from the MusicPlayer class, making it more flexible and maintainable. Furthermore, if we want to add new user interfaces or audio codecs in the future, we can simply create new classes that implement the respective interfaces and inject them into the MusicPlayer class, without needing to modify its code.

Example of Composition Between a Car and its Engine

I often fall back to this example when explaining composition — and in fact, you’ll find something like this in my Dometrain courses. In this composition scenario, a car contains an engine, but the car does not inherit from the engine class. Instead, the car class has a reference to an engine object, which it uses to perform actions such as starting the engine or accelerating. If you start to consider how many different parts go into the car — or even how many parts go into an engine — you can start to see how we can compose objects of other objects.

Let’s have a quick look at some simple code that shows how this is modeled:

public class Engine
{
    // Engine implementation
}

public class Car
{
    private readonly Engine _engine;

    public Car(Engine engine)
    {
        _engine = engine;
    }

    // Car methods and properties
}

By using composition, we can easily swap out different types of engines without modifying the car class. This flexibility allows us to handle various engine configurations, such as gasoline or electric, without changing the car’s implementation.

Composition Example of a House and its Rooms

A house is composed of multiple rooms, each serving a different purpose. Composition can be used to represent this relationship in an object-oriented manner.

public interfac IRoom
{
    // Room properties and methods
}

public class House
{
    private readonly IReadOnlyList<IRoom> _rooms;

    public House(List<Room> rooms)
    {
        _rooms = rooms;
    }

    // House methods and properties
}

By using composition, we can easily create a house of different rooms. The way that this particular House type is set up, we can pass in a collection of IRoom instances and we’ll track them in a field. But because we’re using an IRoom interface, this could allow us to create a house with multiple rooms where we don’t care about the implementation of the room! So if you wanted your dream house to be 50 kitchens, you could absolutely create a Kitchen type that inherits from IRoom and pass in 50 instances of them when you create your house!

Multiple Levels of Composition in C#

To conclude the code examples, let’s go one level deeper. We’ve seen several examples of having one object being composed of one or more other objects, but what if we wanted to illustrate the extension of this?

In this code example, we’ll look at a library:

// public getters and setters just for
// ease-of-use when showing this example
public class Library
{
    public string Name { get; set; }

    public List<BookShelf> BookShelves { get; set; } = new List<BookShelf>();
}

public class BookShelf
{
    public int Number { get; set; }

    public List<Book> Books { get; set; } = new List<Book>();
}

public class Book
{
    public string Title { get; set; }

    public string Author { get; set; }

    public int YearPublished { get; set; }
}

// Example Usage
var myLibrary = new Library
{
    Name = "Central Library",
    BookShelves = new List<BookShelf>
    {
        new BookShelf
        {
            Number = 1,
            Books = new List<Book>
            {
                new Book
                {
                    Title = "C# in Depth",
                    Author = "Jon Skeet",
                    YearPublished = 2019
                },
                new Book
                {
                    Title = "The Pragmatic Programmer",
                    Author = "Andy Hunt & Dave Thomas",
                    YearPublished = 1999
                }
            }
        }
    }
};

In this example, we can see that libraries are made of bookshelves. But we can also see that bookshelves are composed of books that need to go onto the shelves! This shows multiple levels of composition taking place.

Benefits and Considerations of Composition

By breaking down complex systems into smaller, reusable components, composition allows for easier code management and promotes code reuse. Now that we’ve seen some code examples showing how this is done, let’s walk through the advantages and considerations for composition.

Advantages of Using Composition

• Code Reuse: Composition allows us to create smaller, reusable components that can be used in different parts of our codebase. By composing objects together, we can build complex systems by leveraging the functionality and behavior already implemented in those smaller components.

• Flexibility: One of the key benefits of composition is the flexibility it provides. We can easily modify the behavior of a system by adding or removing composed objects without impacting the rest of the codebase. This flexibility makes it easier to adapt and extend our software to meet changing requirements.

• Maintainability: Composition promotes modular and decoupled code, making it easier to maintain and update. By breaking down a system into smaller components, each responsible for a specific task, we can isolate changes and minimize the impact on other parts of the codebase. This makes our codebase more maintainable and reduces the risk of introducing bugs during updates or modifications.

• Testability: When functionality is buried deep in base classes and abstract classes because overuse of inheritance, testing becomes more difficult. Often we need to either implement what is called “fakes” for our tests or we need to get very creative with finding ways to exercise code closer to the base class. With composition often that logic doesn’t need to become as buried and therefore it’s easier to test.

Considerations when Using Composition

While composition offers numerous benefits, there are some considerations to keep in mind when using it in software design:

• Managing the Lifecycle of Composed Objects: Properly managing the lifecycle of composed objects is important to avoid memory leaks or resource allocation issues. Ensuring that objects are appropriately instantiated and disposed of is important when working with composed systems. In more complex systems, it’s important to understand who owns which dependency — especially if it’s shared.

• Interface Usage: I mentioned earlier that composition does not require interfaces, but a side effect can be that people can more easily lean into overusing interfaces. Everything gets an interface! While I do feel that can often help with unit testing — to a certain extent — it can start to become unwieldy when you’re adding them for no purpose just because you see the pattern. I am guilty of this.

• “Newing” it all up: When you have to keep passing dependencies in via the constructor to compose objects, where do these all get made? Well, we often find ourselves adding instantiation code the the entry point and this grows out of control. However, you can use dependency injection — things like Autofac or the built-in IServiceCollection — to make this more streamlined.

Best Practices for Using Composition in C#

When it comes to using composition in C#, there are several best practices and guidelines that can help you design and organize your code in a clear and efficient manner. Here are some tips to help you make the most out of composition in C#:

1. Identify the components: Before you start implementing composition in your code, it’s important to identify the different components or objects that will interact with each other. This will help you determine how to structure your code and which objects should be composed together.

2. Encapsulate functionality: One of the key benefits of composition is that it allows you to encapsulate functionality within separate objects. Each component should have a well-defined and focused responsibility, making it easier to understand, test, and maintain your code. You heard me sneak in “encapsulation” earlier in the article, and here it is again.

3. Avoid tight coupling: Composition promotes loose coupling between objects, which helps increase the flexibility and maintainability of your code. Avoid directly instantiating objects within other objects, as this can create tight dependencies. Pass dependencies in via the constructor and consider using interfaces as required.

4. Favor composition over inheritance: Inheritance can lead to rigid and tightly coupled code. Instead, prefer composition as it allows for more flexible and modular designs. Seriously. It’s more often than not what you’d prefer.

5. Keep classes small and focused: As you compose objects together, strive to keep your classes small and focused on a single responsibility — enter the Single Responsibility Principle (SRP). This helps make your code more readable, testable, and maintainable. If a class becomes too large or complex, consider breaking it down into smaller, more manageable components. Also, avoid having so many tiny thin classes that you’ve gone to the other extreme.

6. Use dependency injection: Dependency injection is a powerful technique that complements composition. It allows you to inject dependencies into an object rather than creating them internally. This helps decouple components and makes it easier to swap out dependencies or mock them for testing. We have helpful frameworks to leverage for this!

That’s quite the list — but it’s relatively easy to keep the core idea in mind: You are making objects up from other objects and not inheriting them.

Wrapping Up Examples of Composition in C#

To recap, I walked through a handful of simple examples of composition in C# — each trying to use real-world objects to make the examples more understandable. I listed out the benefits, considerations, and even the best practices to follow when it comes to leveraging composition. Remember to use composition to model “is made up of” relationships!

If you found this useful and you’re looking for more learning opportunities, consider subscribing to my free weekly software engineering newsletter and check out my free videos on YouTube! Meet other like-minded software engineers and join my Discord community!

Want More Dev Leader Content?

• Follow along on this platform if you haven’t already!

• Subscribe to my free weekly software engineering and dotnet-focused newsletter. I include exclusive articles and early access to videos:
  SUBSCRIBE FOR FREE

• Looking for courses? Check out my offerings:
  VIEW COURSES

• E-Books & other resources:
  VIEW RESOURCES

• Watch hundreds of full-length videos on my YouTube channel:
  VISIT CHANNEL

• Visit my website for hundreds of articles on various software engineering topics (including code snippets):
  VISIT WEBSITE

• Check out the repository with many code examples from my articles and videos on GitHub:
  VIEW REPOSITORY

This article is intended for beginners who want to learn more about inheritance, and as always when I discuss inheritance, I am much more in favor of people leaning into composition. I want to acknowledge this bias because, after 20 years of programming, I have personally made the mistake of using inheritance for everything and seen many others do it too. Something to keep in mind as you read through!

Understanding Inheritance

In object-oriented programming, inheritance is a powerful concept that allows us to define a new class based on an existing class. It enables the new class, called the derived class or subclass, to inherit the properties and behaviors of the existing class, known as the base class or superclass. This inheritance relationship helps to organize and structure code in a meaningful way.

The purpose of inheritance is to promote code reusability and enhance modularity. By inheriting from a base class, we can reuse the code and functionality already defined in it, without having to rewrite it in the derived class. This not only saves time and effort but also promotes consistency across different classes.

Real World Example to Model with Inheritance

To understand inheritance better, let’s consider a real-world analogy. Think of a car manufacturer that produces different models of cars. Each car model shares common features such as the ability to drive, brake, and accelerate. These common features can be thought of as the base class. The specific car models, such as Sedan, SUV, or Hatchback, can be considered as the derived classes. This is because each of these specific car types have an “is a” relationship to the base — they are all cars!

In the analogy, the base class defines the common features that all car models inherit. The derived classes, on the other hand, can add additional features or modify existing ones to meet their specific requirements. For example, the Sedan class may have additional functionality like a sunroof, while the SUV class could have features like 4-wheel drive.

How It Works In C#

Let’s talk about the very basics here. In C#, we can create a base class using the class keyword and specify the common properties and methods. But how do we represent the “is a” relationship?

We can create derived classes using the : symbol followed by the name of the base class, which effectively says this class “is a” some other class! The derived classes can then add their unique properties and methods while inheriting the ones defined in the base class. By using inheritance, we can create a hierarchy of classes, with each level inheriting and extending the functionality of the previous level.

We can organize our code in a hierarchical manner, which for many developers allows them to push common re-usable code into base classes. One of the arguments is that this helps with reusability and maintenance — following the Don’t Repeat Yourself (DRY) principle — but my own bias suggests this is often not an ideal way to have reusable code. But we’ll see composition in object-oriented programming later.

Creating Inheritance Relationships in C#

In object-oriented programming, inheritance allows us to create relationships between classes. With inheritance, we can define a base class that serves as a blueprint, and then create derived classes that inherit properties and methods from the base class.

To create an inheritance relationship between classes in C#, we use the colon (:) symbol. This was described earlier, so let’s take a look at the syntax for declaring a base class and a derived class in this example:

public class Shape
{
    // Base class properties and methods
}

public class Circle : Shape
{
    // Derived class properties and methods
}

In the example above, the class Shape is the base class, and the class Circle is the derived class. The colon (:) symbol indicates that the Circle class inherits from the Shape class.

When a class inherits from a base class, it automatically inherits all the public and protected properties and methods of the base class. This means that the Circle class will have access to all the properties and methods defined in the Shape class — in this example so far there are none. So let’s continue!

The Virtual and Override Keywords in C#

Sometimes, we may want to modify or extend the behavior of a method that is inherited from the base class. In C#, we can do this by using the override keyword along with the virtual keyword. Here’s an example:

public class Shape
{
    public virtual void Draw()
    {
        // Base class implementation
    }
}

public class Circle : Shape
{
    public override void Draw()
    {
        // Derived class implementation
    }
}

In this example, the Draw method is declared as virtual in the Shape class, which means it can be overridden in derived classes. The Circle class overrides the Draw method and provides its own implementation.

Abstract Classes and Abstract Members in C#

We can use another keyword in C# called abstract to offer different behavior from the base class. If we have an abstract class, the specific type cannot be instantiated, but derived classes inheriting from it can be. Abstract classes can also offer shared functionality by defining members that are accessible to derived classes.

However, abstract classes can also have abstract members! These abstract members, unlike virtual members, do not provide default functionality — so derived classes MUST provide an implementation using the override keyword that we saw previously.

Let’s see that same example with shapes but this time with a twist:

public abstract class Shape
{
    public abstract void Draw();
}

public class Circle : Shape
{
    public override void Draw()
    {
        // Derived class implementation that *MUST* be implemented
    }
}

In the example above, the derived class looks identical to what we saw in the previous example. However, a fundamental difference is that with virtual we could optionally override it — with abstract , we must override and provide an implementation.

Accessing Base Class Members in C#

To access the members of the base class from the derived class, we use the base keyword. This allows us to call the base class constructor, access base class properties, or invoke base class methods. Here’s an example:

public class Shape
{
    public string Color { get; set; }
}

public class Circle : Shape
{
    public Circle(string color)
    {
        base.Color = color; // Accessing base class properties
    }
}

In the above example, the Circle class constructor takes a color parameter and sets the Color property inherited from the base class. This only works with access modifiers more visible than private, otherwise the derived class cannot see the member.

The above example does not require the base keyword, even though it is correct. This is because there is not a conflicting current-scope member called Color that would conflict — the only Color is in the base. If you were overriding a virtual member and wanted to call the base implementation still from your override, this is a great use for explicitly putting the base keyword.

Practical Scenarios of Using Inheritance in C#

Let’s check out some practical examples of when and how to use inheritance in software development.

Modeling the Relationship Between Employees

Let’s consider a scenario where we are building a payroll system for a company. The system needs to handle different types of employees, such as full-time employees, part-time employees, and contractors. Instead of creating separate classes for each type, we can use inheritance to model their relationship. That’s because we can say that each type of employee “is an” employee — that’s an inheritance relationship.

We can create a base class called “Employee” which contains common attributes like name, id, and salary. Then, we can create derived classes like “FullTimeEmployee,” “PartTimeEmployee,” and “Contractor” that inherit from the base “Employee” class. By doing this, we can reuse the common attributes and behaviors defined in the base class, while also adding specific attributes or behaviors unique to each type of employee.

Here’s some example code to show this relationship:

public class Employee
{
    public Employee(
        string name,
        int id,
        decimal salary)
    {
        Name = name;
        Id = id;
        Salary = salary;
    }

    public string Name { get; set; }

    public int Id { get; set; }

    public decimal Salary { get; set; }

    public virtual void DisplayEmployeeInfo()
    {
        Console.WriteLine($"Name: {Name}, ID: {Id}, Salary: {Salary}");
    }
}

public class FullTimeEmployee : Employee
{
    public FullTimeEmployee(
        string name,
        int id,
        decimal salary) : 
        base(name, id, salary)
    {
    }
}

public class PartTimeEmployee : Employee
{
    public PartTimeEmployee(
        string name,
        int id,
        decimal salary,
        int workingHours) :
        base(name, id, salary)
    {
        WorkingHours = workingHours;
    }

    public int WorkingHours { get; set; }

    public override void DisplayEmployeeInfo()
    {
        base.DisplayEmployeeInfo();
        Console.WriteLine($"Working Hours: {WorkingHours}");
    }
}

public class Contractor : Employee
{
    public Contractor(
        string name,
        int id,
        decimal salary,
        DateTime contractEndDate) :
        base(name, id, salary)
    {
        ContractEndDate = contractEndDate;
    }

    public DateTime ContractEndDate { get; set; }

    public override void DisplayEmployeeInfo()
    {
        base.DisplayEmployeeInfo();
        Console.WriteLine($"Contract End Date: {ContractEndDate.ToShortDateString()}");
    }
}

Can you identify the custom behavior for the derived classes above? What keywords do you need to be looking for?

Reusability and Maintainability

Inheritance not only allows us to model relationships but also promotes code reuse and maintainability. Consider a scenario where we are developing a game. We can have a base class called “Character” which defines common attributes and methods for all characters in the game, such as health points and attack behavior. Then, we can create derived classes like “Player” and “Enemy” that inherit from the base “Character” class.

By doing this, we can reuse the common attributes and methods defined in the base class, preventing code duplication. Additionally, if we need to make changes to the common attributes or behaviors, we only need to update the code in one place (the base class), which simplifies maintenance and reduces the chances of introducing bugs.

public abstract class Character
{
    protected Character(
        string name,
        int healthPoints)
    {
        Name = name;
        HealthPoints = healthPoints;
    }

    public int HealthPoints { get; set; }
    public string Name { get; set; }

    public virtual void Attack(Character target)
    {
        // Default attack behavior
    }
}

public class Player : Character
{
    public Player(
        string name,
        int healthPoints)
        : base(name, healthPoints)
    {
    }

    public override void Attack(Character target)
    {
        // Player-specific attack behavior
    }
}

public class Enemy : Character
{
    public Enemy(
        string name,
        int healthPoints)
        : base(name, healthPoints)
    {
    }

    public override void Attack(Character target)
    {
        // Enemy-specific attack behavior
    }
}

Design and Planning Considerations

When utilizing inheritance in software engineering, proper design and planning are important. It’s important to identify the entities and their relationships, and carefully decide which attributes and behaviors should be included in the base class versus the derived classes. Inheritance should be used with caution, keeping in mind the principle of “favor composition over inheritance” to avoid excessive class hierarchies and inheritance chains.

While this isn’t a rule, a helpful guideline I find is that if I’m building classes that define logic or algorithms, inheritance is generally a bad fit. I want to compose these systems with other systems. When I’m defining data structures, composition can still be an excellent option, but this is where I find inheritance might be a good fit. As these two statements suggest, composition is more frequently something I find can be used effectively, and it’s actually more rare that I find inheritance a good fit. By following good design principles and leveraging inheritance appropriately, we can create more maintainable and reusable code in our software projects.

Common Pitfalls and Best Practices in Inheritance

When working with inheritance in C#, there are some common pitfalls that developers should be aware of to ensure efficient and effective code. Let’s take a look at some of the key considerations.

Avoid Deep Inheritance Hierarchies

One common mistake in inheritance is creating deep hierarchies with many levels of subclasses. While it may seem like a good idea at first to divide functionality into smaller subclasses, it can quickly become complex and difficult to maintain. Deep hierarchies can lead to code duplication, increased complexity, and decreased readability. It’s advisable to keep the inheritance hierarchy as shallow as possible to maintain simplicity and flexibility in your code.

Understanding the “is-a” Relationship

Inheritance is all about creating an “is-a” relationship between classes. It means that a subclass is a specific type of the base class. For example, in a shape hierarchy, a circle is a specific type of shape. This concept is important to the design and implementation of inheritance. Understanding the “is-a” relationship is important to ensure that subclasses inherit the appropriate attributes and behaviors from the base class.

Best Practices for Using Inheritance Effectively

To use inheritance effectively and efficiently in C# programming, consider the following best practices:

• Design for Reusability: Inheritance allows you to reuse code from the base class in the subclass. Make sure that the base class is well-designed and provides a solid foundation for the subclasses to build upon. Remember, you don’t need inheritance to be able to re-use code… the purpose of inheritance is to model an “is a” relationship between types.

• Prioritize Composition over Inheritance: In some (probably most) cases, composition may be a better choice than inheritance. Instead of using a subclass, consider using composition to create a class that contains instances of other classes. This approach generally provides more flexibility and reduces the coupling between classes. Using an “is made of” relationship instead of an “is a” relationship is very prominent in systems we build, especially when it comes to logic. “is a” relationships for inheritance may be a better fit in representing data transfer objects instead.

• Properly Use Abstract Classes and Interfaces: Abstract classes and interfaces play a significant role in inheritance. Abstract classes provide a blueprint for subclasses and can implement common functionality, while interfaces define a contract that classes must adhere to. Remember, if you are just looking for a spot for common code to give consideration if composition will be a better fit instead of just trying to drive more code into a base class.

• Avoid Fragile Base Class Problem: The fragile base class problem occurs when modifications to the base class inadvertently break functionality in its subclasses. To avoid this, ensure that changes to the base class, such as adding or modifying methods, do not have an unexpected impact on the subclasses. Again, this becomes a BIG problem when you have complex inheritance hierarchies with logic scattered between the base class and multiple derived classes — and much of the time this can be avoided with composition.

Remember to keep your inheritance hierarchies shallow, understand the “is-a” relationship, and design for reusability. With an understanding of inheritance concepts and best practices, remember to give strong consideration as to whether composition is a better fit. You might just be using inheritance because you feel more comfortable with it instead of for better OOP modeling reasons.

Wrapping Up Examples of Inheritance in C#

I’m hopeful you caught at least a few instances throughout the article of me recommending that you consider composition over inheritance because truly I do see inheritance get overused. I was responsible for a LOT of code early in my career that overused inheritance and we ultimately had to rewrite a significant portion of it because of how much it crippled our ability to extend the code. It broke most of the guidelines in the best practices section of this article.

With that said though, inheritance has its time and its place. I think if you take the time to understand both of these paradigms you can see how to use them effectively.

If you found this useful and you’re looking for more learning opportunities, consider subscribing to my free weekly software engineering newsletter and check out my free videos on YouTube! Meet other like-minded software engineers and join my Discord community!

Want More Dev Leader Content?

• Follow along on this platform if you haven’t already!

• Subscribe to my free weekly software engineering and dotnet-focused newsletter. I include exclusive articles and early access to videos:
  SUBSCRIBE FOR FREE

• Looking for courses? Check out my offerings:
  VIEW COURSES

• E-Books & other resources:
  VIEW RESOURCES

• Watch hundreds of full-length videos on my YouTube channel:
  VISIT CHANNEL

• Visit my website for hundreds of articles on various software engineering topics (including code snippets):
  VISIT WEBSITE

• Check out the repository with many code examples from my articles and videos on GitHub:
  VIEW REPOSITORY

No — I won’t be doing a deep dive into complex patterns and super wild and fancy things that you can do with regular expressions. Nope. Just some simple C# examples to get you pointed in the right direction!

1 – Regex Starts With

When working with regular expressions in C#, you can easily match strings that start with a specific pattern. This can be useful in scenarios where you need to find or extract strings that have a particular prefix. And yeah — I know you’re probably thinking “Hey Nick, don’t we already have string.StartsWith to use?” — and you’re right! But you can’t use that to match patterns more complex than a string directly.

To pattern match at the beginning of a string, you’ll need to use the caret (^) symbol as an anchor in your regular expression pattern. The caret symbol represents the start of a line or string in regular expressions, so by placing it at the beginning of your pattern, you ensure that the match you are looking for occurs at the start of the string.

To demonstrate this, consider the following code example:

using System;
using System.Collections.Generic;
using System.Text.RegularExpressions;

List<string> inputs = new()
{
    "Hello, World!",
    "Something something Hello!",
    "  Hello",
    "Hello from Dev Leader!",
};

string pattern = "^Hello";
Regex regex = new Regex(pattern);

foreach (var input in inputs)
{
    Match match = regex.Match(input);
    Console.WriteLine(
        $"'{input}' {(match.Success ? "did" : "did not")} " +
        "match the string starting with the pattern.");
}

In this example, I’ve created a list of input strings that we can exercise our regular expression against. We’ll use a caret at the beginning of the pattern, which otherwise just says “Hello”, so effectively we’re looking for strings that start with Hello. You can try it out directly in your browser with this DotNetFiddle:

Now a question you should be asking yourself is… is this a good example of using a regular expression instead of string.StartsWith? What do you think the performance of this might be like? Try comparing them in BenchmarkDotNet to find out!

2 – Regex Ends With

If you read the previous section: We’re talking about going the other way now. If you didn’t read the previous section: Go read that and then come back and read the first sentence in this section.

Choose your own adventure! And now we can discuss how to match the end of a string with our regex pattern. To match patterns that end with a particular string, we can use the dollar sign ($) symbol as an anchor in our regular expression pattern. The dollar sign represents the end of the string, ensuring that the specified pattern is only matched if it occurs at the end. Basically the opposite of what we saw with the caret symbol.

Let’s consider an example where we want to find all the words in a given text that end with the suffix “ing”. We can achieve this using regular expressions in C# with the following code snippet:

using System;
using System.Collections.Generic;
using System.Text.RegularExpressions;

List<string> inputs = new()
{
    "Coding", // match
    "I love programming!", // no match
    "Coding is fun!", // no match
    "I love programming", // match
};

string pattern = "ing$";
Regex regex = new Regex(pattern);

foreach (var input in inputs)
{
    Match match = regex.Match(input);
    Console.WriteLine(
        $"'{input}' {(match.Success ? "did" : "did not")} " +
        "match the string ending with the pattern.");
}

Take note of the input strings above because all of them contain “ing” but not all of them end with “ing”. Which ones will match? If you want to try the Regex ends with example in your browser, check out this DotNetFiddle:

3 – Regex Is Match

While we’ve been looking at comparisons to other string methods like StartsWith and EndsWith, we can continue this comparison with regex in C#. We know that regex will allow us to do more complex pattern matching compared to these string method variations, so what if we simply want to know if there’s a pattern match? If you wanted something similar to string.Contains just to know if a pattern matches a string, we can use the Regex.IsMatch() method to perform the pattern matching.

Note that Regex.IsMatch() will simply return a boolean result instead of a Match type. If you want more information about when your match succeeds, much like in the earlier examples, then you can just use the Match method or even the Matches to get all matching instances within the source string. I wanted to spice it up a bit and use this example just to compare to string.Contains, but if you wanted to compare it to something closer to string.IndexOf to find the position, switch back to the other methods.

If we don’t care about beginning or ending matching, we can ditch the ^ and $ symbols in our regular expressions. Let’s check out this code example that has a slightly more advanced pattern to match:

using System;
using System.Collections.Generic;
using System.Text.RegularExpressions;

List<string> inputs = new()
{
    "Nick", // no match
    "Nick1", // no match
    "1Nick", // no match
    "Nick42", // match
    "42Nick", // match
    "4Nick2", // match
    "42", // match
    "1337", // match
    "6", // no match
};

string pattern = "[0-9]+[a-zA-Z]*[0-9]+";
Regex regex = new Regex(pattern);

foreach (var input in inputs)
{
    bool isMatch = regex.IsMatch(input);
    Console.WriteLine(
        $"'{input}' {(isMatch ? "did" : "did not")} " +
        "match the pattern.");
}

In this example, the Regex.IsMatch() method takes in the input variable and the pattern variable was provided to the Regex instance at creation time. If you examine the pattern that we’re trying to match, we need to have at least 2 numbers with either 0 or many characters from a to z (case not being considered). But what about if we had 2 numbers that were separated by a character that wasn’t in the English alphabet? Try it out for yourself with this DotNetFiddle:

Wrapping Up Regular Expressions in C#

As you can see from these examples, regular expressions in C# aren’t so scary, right? They’re just a little bit more complicated than doing some other string operations.

At least, on the surface.

There are regex options in C# to explore and, of course, the regular expressions that we write can get incredibly complex. Regular expressions can be a powerful tool for us to use, but keep in mind that you’ll want to balance things out. Consider readability, performance, and other characteristics if you start heavily relying on regular expressions for matching patterns in your applications!

If you found this useful and you’re looking for more learning opportunities, consider subscribing to my free weekly software engineering newsletter and check out my free videos on YouTube! Meet other like-minded software engineers and join my Discord community!

Want More Dev Leader Content?

• Follow along on this platform if you haven’t already!

• Subscribe to my free weekly software engineering and dotnet-focused newsletter. I include exclusive articles and early access to videos:
  SUBSCRIBE FOR FREE

• Looking for courses? Check out my offerings:
  VIEW COURSES

• E-Books & other resources:
  VIEW RESOURCES

• Watch hundreds of full-length videos on my YouTube channel:
  VISIT CHANNEL

• Visit my website for hundreds of articles on various software engineering topics (including code snippets):
  VISIT WEBSITE

• Check out the repository with many code examples from my articles and videos on GitHub:
  VIEW REPOSITORY

And don’t worry: Not only are there code examples that you can copy and paste, but you can try them out right in your browser thanks to DotNetFiddle.

What is a Regular Expression?

Regular expressions, often referred to as regex, are powerful tools used for pattern matching in text. They allow you to define a search pattern that can be used to find, replace, or manipulate specific parts of a string. Regular expressions provide a concise and flexible way to search for and identify specific patterns within text data.

In software engineering, regular expressions are particularly useful for tasks such as data validation, text parsing, and pattern extraction. They can be used in a wide range of scenarios, including web development, data processing, and text analysis. Regular expressions can save you time and effort by providing a more efficient and reliable approach to handling text manipulation tasks.

Here are a bunch of practical examples you could consider using a regular expression for:

1. Validating Email Addresses: Say you are developing a web application that requires users to provide valid email addresses during the registration process. With regular expressions, you can quickly validate if an email address provided by the user adheres to the standard format, ensuring its correctness before further processing.

2. Searching and Replacing Text: Imagine you have a large document and need to replace all occurrences of a particular word or phrase with another. Instead of manually searching through the entire document, you can use regular expressions to perform the substitution task efficiently and accurately.

3. Extracting Data from Text: Suppose you have a log file containing lines of data, but you are only interested in retrieving specific pieces of information, such as timestamps or error messages. Regular expressions enable you to extract the relevant data by identifying patterns within the log entries, saving you valuable time when analyzing and troubleshooting issues.

These are just a few examples of how regular expressions can be leveraged in your applications. In C#, the .NET framework provides a regex library that offers us the power to match all sorts of strings that we’re interested in. In the following sections, I’ll provide code examples for how to work with regular expressions in C#.

Getting Started with Regular Expressions in C#

To begin using regular expressions in C#, you need to understand how to create and work with Regex objects, which are part of the System.Text.RegularExpressions namespace. So to start, let’s get this namespace included in your C# code. You can do this by adding the following using statement at the top of your C# file:

using System.Text.RegularExpressions;

Once you have included the namespace, you can create a Regex object to represent your regular expression pattern. The Regex class provides various constructors that allow you to specify the pattern and any additional options — but we’ll just start with the default C# regex options for now. For example, to create a Regex object that matches the word “hello” in a string, you can use the following code:

Regex regex = new Regex("hello");

Using Regex.Match in C#

After creating the Regex object, you can use its methods to perform pattern-matching operations on strings. The most commonly used method is Match, which searches for the first occurrence of the pattern in a given string. Here is a basic example that demonstrates how to use regular expressions for pattern matching in C#:

using System;
using System.Text.RegularExpressions;

string input = "Hello, World!";
Regex regex = new Regex("Hello");
Match match = regex.Match(input);

if (match.Success)
{
    Console.WriteLine($"Pattern found: {match.Value}");
}
else
{
    Console.WriteLine("Pattern not found.");
}

In this example, we create a Regex object to match the word “Hello” and then use the Match method to search for a match in the input string “Hello, World!”. The Match method returns a Match object, which contains information about the first occurrence of the pattern. We can use the Success property to check if a match was found and the Value property to retrieve the matched string.

You can check out this DotNetFiddle to run this C# regex example right in your browser!

Using Regex.Matches in C#

What happens if we want to match more than one part of the input string though? That’s where the Matches method comes into play, which will also give us a MatchCollection return type to work with. Let’s see it in action:

using System;
using System.Text.RegularExpressions;

string input = "Hello, World!";
Regex regex = new Regex("Hello");
MatchCollection matches = regex.Matches(input);

if (matches.Count > 0)
{
    Console.WriteLine("Pattern(s) found:");
    foreach (Match match in matches)
    {
        Console.WriteLine($"t {match.Value}");
    }
}
else
{
    Console.WriteLine("Pattern not found.");
}

You can see in the example above that if we can enumerate the collection of matches instead of just dealing with a single. And if you want to try it for yourself and experiment, you can use this dotnetfiddle to run the example of Regex.Matches in C#:

The Various Regex Options in C#

When working with regular expressions in C#, there are several options that can be used to modify the behavior of the pattern matching. These options are defined by the RegexOptions enumeration in C#. Because this is a flag enum, we can combine the different enum values to mix and match these C# regex options to get the desired behavior we want.

Let’s take a closer look at some commonly used options and understand their use in different scenarios so that you can make informed decisions and leverage regex in C# more effectively!

RegexOptions.Compiled

This option improves performance by precompiling the regular expression pattern into an assembly. It’s especially useful when the same regular expression pattern is used repeatedly. By compiling the pattern once, subsequent matches can be performed more efficiently. To use this option, simply add RegexOptions.Compiled as a parameter when creating your Regex object.

Let’s consider an example where we could benchmark the results of using this option or not using BenchmarkDotNet:

using System;
using System.Text.RegularExpressions;

using BenchmarkDotNet.Attributes;
using BenchmarkDotNet.Running;

[MemoryDiagnoser]
[ShortRunJob]
public sealed class EmailValidationBenchmark
{
    // NOTE: you could (should) extend this example
    // to try out all sorts of emails and collections
    // of emails!
    private const string TestEmail = "example@example.com";
    private const string Pattern = @"^[a-zA-Z0-9._+-]+@[a-zA-Z0-9.-]+.[a-zA-Z]{2,}$";

    private static readonly Regex EmailRegexCompiled = new Regex(
        Pattern,
        RegexOptions.Compiled
    );

    private static readonly Regex EmailRegexNonCompiled = new Regex(
        Pattern
    );

    [Benchmark]
    public bool ValidateEmailWithCompiledOption()
    {
        return EmailRegexCompiled.IsMatch(TestEmail);
    }

    [Benchmark(Baseline = true)]
    public bool ValidateEmailWithoutCompiledOption()
    {
        return EmailRegexNonCompiled.IsMatch(TestEmail);
    }
}

class Program
{
    static void Main(string[] args)
    {
        var summary = BenchmarkRunner.Run<EmailValidationBenchmark>();
    }
}

Try this example out — or, better yet, try setting up a benchmark like this for your own regex and seeing if compiled makes a difference for you! Do you notice if there’s a difference in memory usage or just runtime?

Next question for you to try in your benchmarks: Do you want to be creating a new regex with the compiled flag on every time you use it, or is there performance overhead for doing that? Measure it and see if there’s a benefit to doing the compilation of the regex ONCE and storing that regex in an instance variable for re-use!

RegexOptions.IgnoreCase

This option enables case-insensitive matching, allowing the regular expression pattern to match both uppercase and lowercase characters. This is important to note, because if you weren’t already aware — yes, regex is going to be case-sensitive. Hopefully you haven’t had too many headaches over this yet!

By using this option, when searching for the word “apple” using the pattern “apple”, enabling RegexOptions.IgnoreCase would match “apple”, “Apple”, and “APPLE”. To use this option, include RegexOptions.IgnoreCase as a parameter when creating your Regex object. We can see this in action in the following example:

using System;
using System.Text.RegularExpressions;


string input1 = "I love eating apples!";
string input2 = "APPLES are great for health.";
string input3 = "Have you seen my Apple?";

Console.WriteLine($"Input 1 contains 'apple': {ContainsApple(input1)}");
Console.WriteLine($"Input 2 contains 'apple': {ContainsApple(input2)}");
Console.WriteLine($"Input 3 contains 'apple': {ContainsApple(input3)}");

static bool ContainsApple(string input)
{
    // hmmm... should we have pulled this out
    // and used the compiled flag?
    Regex appleRegex = new Regex(
        "apple",
        RegexOptions.IgnoreCase);
    return appleRegex.IsMatch(input);
}

RegexOptions.Multiline

This option changes the behavior of the ^ and $ anchors when used in the pattern. By default, ^ matches the start of the input string and $ matches the end of the input string. However, with RegexOptions.Multiline enabled, ^ also matches the start of each line within the input string and $ matches the end of each line. This option is particularly useful when dealing with multi-line input.

To use this option, include RegexOptions.Multiline as a parameter when creating your Regex object, which you can see in this example below! We’ll use this code to look for lines that start with a comment character denoted by the hashtag/pound symbol, #:

using System;
using System.Text.RegularExpressions;

string multiLineText = 
    """
    This is some sample text.
    # This is a comment.
    And here's another line.
    # Another comment.
    """;

foreach (var comment in FindComments(multiLineText))
{
    Console.WriteLine(comment);
}

static string[] FindComments(string input)
{
    // Use RegexOptions.Multiline to treat ^ as the start of each line.
    Regex commentRegex = new Regex("^#.*$", RegexOptions.Multiline);

    var matches = commentRegex.Matches(input);
    string[] comments = new string[matches.Count];
    for (int i = 0; i < matches.Count; i++)
    {
        comments[i] = matches[i].Value;
    }

    return comments;
}

If you want to play around with this example right in your browser, check out this DotNetFiddle:

Wrapping Up Regex Options in C#

In this article, I gave you a brief rundown of some simple methods that we have access to in C# for working with regular expressions. But beyond that, we got to see a handful of different regex options in C# that we have access to that can change the behavior of our matching!

Try out the code examples! Play around with them in DotNetFiddle! Consider benchmarking your code with BenchmarkDotNet if you’re looking to tune the performance of your pattern matching using regular expressions in C#.

If you found this useful and you’re looking for more learning opportunities, consider subscribing to my free weekly software engineering newsletter and check out my free videos on YouTube! Meet other like-minded software engineers and join my Discord community!

Want More Dev Leader Content?

• Follow along on this platform if you haven’t already!

• Subscribe to my free weekly software engineering and dotnet-focused newsletter. I include exclusive articles and early access to videos:
  SUBSCRIBE FOR FREE

• Looking for courses? Check out my offerings:
  VIEW COURSES

• E-Books & other resources:
  VIEW RESOURCES

• Watch hundreds of full-length videos on my YouTube channel:
  VISIT CHANNEL

• Visit my website for hundreds of articles on various software engineering topics (including code snippets):
  VISIT WEBSITE

• Check out the repository with many code examples from my articles and videos on GitHub:
  VIEW REPOSITORY

Besides, maybe there’s someone out there with something like this on their hot-path that needs to squeeze a bit more out of their application 🙂

What Are Collection Initializers and Collection Expressions in C#?

In one of my most recent articles, I explain the basics of collection initializers with some simple code examples. Simple put, instead of manually writing code like the following to initialize a collection:

List<string> devLeaderCoolList = new List<string>();
devLeaderCoolList.Add("Hello");
devLeaderCoolList.Add(", ");
devLeaderCoolList.Add("World!");

… we can instead reduce it to something more succinct like the following:

List<string> devLeaderCoolList = [ "Hello", ", ", "World!" ];

Pretty neat, right? And this collection expression syntax is even more lightweight than we’ve had access to in recent times.

But syntax and readability aside (Not to minimize the benefits of readability of code, but I’m trying not to put you to sleep), what about the performance?! I bet you didn’t even consider that with all of the different collection initializer syntax that we have that we’d see a performance difference!

Well, Dave Callan got me thinking about that when he posted this on LinkedIn:

This image was originally posted by Dave Callan on LinkedIn, and that has inspired this entire article. So let’s jump into some benchmarks!

Exploring List Collection Initializer Performance in C#

This section will detail the benchmarks for initializing lists in C# in various ways. I’ll provide coverage on different collection initializers, the newer collection expression syntax, and even compare it to doing it manually! Surely, adding everything by hand would be slower than setting ourselves up for success by doing it all with a collection initializer — but we should cover our bases.

I will not be covering the spread operator in these benchmarks because I’d like to focus on that more for collection combination benchmarks. Admittedly, yes, it is still creating a collection… but I feel like the use case is different and I’d like to split it up.

I’ll be using BenchmarkDotNet for all of these benchmarks, so if you’re not familiar with using BenchmarkDotNet you can check out this video and see how to use it for yourself:

The List Benchmark Code

With the BenchmarkDotNet NuGet installed, here’s what I am using at the entry point to kick things off (for all benchmark examples in this article):

using BenchmarkDotNet.Attributes;
using BenchmarkDotNet.Running;

using System.Reflection;

BenchmarkRunner.Run(
    Assembly.GetExecutingAssembly(),
    args: args);

It’s not very exciting — but I wanted to show you there’s nothing fancy going on here. Just running all of the benchmarks we have access to. And here is the list benchmark code:

[MemoryDiagnoser]
[MediumRunJob]
public class ListBenchmarks
{
    private static readonly string[] _dataAsArray = new string[]
    {
        "Apple",
        "Banana",
        "Orange",
    };

    private static IEnumerable<string> GetDataAsIterator()
    {
        yield return "Apple";
        yield return "Banana";
        yield return "Orange";
    }

    [Benchmark(Baseline = true)]
    public List<string> ClassicCollectionInitializer_NoCapacity()
    {
        return new List<string>()
        {
            "Apple",
            "Banana",
            "Orange",
        };
    }

    [Benchmark]
    public List<string> ClassicCollectionInitializer_SetCapacity()
    {
        return new List<string>(3)
        {
            "Apple",
            "Banana",
            "Orange",
        };
    }

    [Benchmark]
    public List<string> CollectionExpression()
    {
        return
        [
            "Apple",
            "Banana",
            "Orange",
        ];
    }

    [Benchmark]
    public List<string> CopyConstructor_Array()
    {
        return new List<string>(_dataAsArray);
    }

    [Benchmark]
    public List<string> CopyConstructor_Iterator()
    {
        return new List<string>(GetDataAsIterator());
    }

    [Benchmark]
    public List<string> ManuallyAdd_NoCapacitySet()
    {
        List<string> list = [];
        list.Add("Apple");
        list.Add("Banana");
        list.Add("Orange");
        return list;
    }

    [Benchmark]
    public List<string> ManuallyAdd_CapacitySet()
    {
        List<string> list = new(3);
        list.Add("Apple");
        list.Add("Banana");
        list.Add("Orange");
        return list;
    }
}

Note in the above code example the baseline we will be comparing against is what I consider the traditional collection initializer:

return new List<string>()
{
    "Apple",
    "Banana",
    "Orange",
};

The List Benchmark Results

And of course, I wouldn’t make you go compile and run these yourself, so let’s look at the results below:

Let’s go through the results from worst to best based on the Ratio column (Higher is worse):

• 3.31X – Using a copy constructor where we pass in an iterator is the worst performing. This is likely due to the overhead of creating an iterator, especially for such a small and simple overall operation AND because there’s no known capacity when using an iterator.

• 1.76X – Using a copy constructor even with an array isn’t great. If you know what you need to put into the collection, you’re better off using a normal classic collection initializer. An argument for both the copy constructors though is that if this isn’t on the hot path it might be more maintainable in your code to copy a collection vs instantiate it with duplicated values manually.

• 1.10X – Manually adding things to a collection without setting a capacity is only a little bit slower than using a collection initializer with no capacity! 10% slower based on these benchmarks.

• 1.0X – The baseline here is a classic collection initializer with no capacity set

Here is where we start to see some speed up!

• 0.64X – Using a collection expression was 64% of the time! That’s a pretty dramatic improvement for what just looks like a syntax change, and that’s very much inline with what Dave Callan’s screenshot shows.

• 0.61X – Manually adding things to a list that has an initial capacity is actually FASTER than these other collection initializers and collection expression that we’ve seen so far!

• 0.53X – Using a classic collection initializer but providing the capacity is almost HALF the time!

One of the common themes here is that providing a capacity is a BIG performance gain. We realized an ~87% gain over our baseline simply by providing it a capacity. Side note: why couldn’t the compiler do some kind of optimization here if we know the collection size in the braces?!

Exploring Dictionary Collection Initializer Performance in C#

Dictionaries don’t yet have a fancy collection expression that uses square brackets and removes even more bloat, but we do have several variations of collection initializers to use. These benchmarks will be very similar, also using BenchmarkDotNet, and they also use the same entry point program — so I won’t repeat it here.

I know dictionaries can have two types to work with, and I wanted to keep this similar to the list example — not because they are similar implementations of collections, but because I didn’t want to just pollute this article with more variations of things for no reason. I decided to go with a Dictionary<string, string> where the keys are what we already looked at, and the values are just some short strings to work with that are unique.

The Dictionary Benchmark Code

Here’s the code for the dictionary benchmarks:

[MemoryDiagnoser]
[MediumRunJob]
public class DictionaryBenchmarks
{
    private static readonly Dictionary<string, string> _sourceData = new()
    {
        ["Apple"] = "The first value",
        ["Banana"] = "The next value",
        ["Orange"] = "The last value",
    };

    private static IEnumerable<KeyValuePair<string, string>> GetDataAsIterator()
    {
        foreach (var item in _sourceData)
        {
            yield return item;
        }
    }

    [Benchmark(Baseline = true)]
    public Dictionary<string, string> CollectionInitializer_BracesWithoutCapacity()
    {
        return new Dictionary<string, string>()
        {
            { "Apple", "The first value" },
            { "Banana", "The next value" },
            { "Orange",  "The last value" },
        };
    }

    [Benchmark]
    public Dictionary<string, string> CollectionInitializer_BracesWithCapacity()
    {
        return new Dictionary<string, string>(3)
        {
            { "Apple", "The first value" },
            { "Banana", "The next value" },
            { "Orange",  "The last value" },
        };
    }

    [Benchmark]
    public Dictionary<string, string> CollectionInitializer_BracketsWithoutCapacity()
    {
        return new Dictionary<string, string>()
        {
            ["Apple"] = "The first value",
            ["Banana"] = "The next value",
            ["Orange"] = "The last value",
        };
    }

    [Benchmark]
    public Dictionary<string, string> CollectionInitializer_BracketsWithCapacity()
    {
        return new Dictionary<string, string>(3)
        {
            ["Apple"] = "The first value",
            ["Banana"] = "The next value",
            ["Orange"] = "The last value",
        };
    }

    [Benchmark]
    public Dictionary<string, string> CopyConstructor_Dictionary()
    {
        return new Dictionary<string, string>(_sourceData);
    }

    [Benchmark]
    public Dictionary<string, string> CopyConstructor_Iterator()
    {
        return new Dictionary<string, string>(GetDataAsIterator());
    }

    [Benchmark]
    public Dictionary<string, string> ManuallyAdd_NoCapacitySet()
    {
        Dictionary<string, string> dict = [];
        dict.Add("Apple", "The first value");
        dict.Add("Banana", "The next value");
        dict.Add("Orange", "The last value");
        return dict;
    }

    [Benchmark]
    public Dictionary<string, string> ManuallyAdd_CapacitySet()
    {
        Dictionary<string, string> dict = new(3);
        dict.Add("Apple", "The first value");
        dict.Add("Banana", "The next value");
        dict.Add("Orange", "The last value");
        return dict;
    }

    [Benchmark]
    public Dictionary<string, string> ManuallyAssign_NoCapacitySet()
    {
        Dictionary<string, string> dict = [];
        dict["Apple"] = "The first value";
        dict["Banana"] = "The next value";
        dict["Orange"] = "The last value";
        return dict;
    }

    [Benchmark]
    public Dictionary<string, string> ManuallyAssign_CapacitySet()
    {
        Dictionary<string, string> dict = new(3);
        dict["Apple"] = "The first value";
        dict["Banana"] = "The next value";
        dict["Orange"] = "The last value";
        return dict;
    }
}

You’ll notice two themes creeping up:

• We have two different flavors of collection initializers: square brackets and curly braces

• We can manually instantiate a dictionary by adding or directly assigning (which are NOT the exact same behavior)

Otherwise, we still have capacity considerations just like the list benchmarks!

The Dictionary Benchmark Results

The dictionary benchmarks are as follows:

Doing the same exercise of highest to lowest ratio:

• 2.03X – Copy constructor with iterator strikes again! I suspect for similar reasons — no count for knowing the capacity and the overhead of creating the iterator relative to the number of items.

• 1.02X – Manually adding items to the dictionary WITH the capacity set was almost the exact same performance as using the collection initializer! This one to me is very surprising given the known capacity usually speeds things up a great deal.

• 1.0X – Our classic collection initializer using curly braces and not setting the capacity is our baseline

Everything beyond here is technically faster according to our benchmarks:

• 0.96X – In the case where we provide a capacity, we’re a little bit faster than the baseline using the same syntax.

• 0.95X – Manually assigning items without a known capacity is even faster, and about 5% faster than the baseline. I still wouldn’t be making much of a fuss here.

• 0.94X – Classic collection initializer but using square brackets and not setting a capacity is ~6% faster than the baseline.

• 0.90X – Manually assigning items when the capacity is known is ~11% faster than the baseline, so we’re starting to pick up steam a little bit here!

• 0.87X – Classic collection initializer but using square brackets WITH a known capacity is ~15% faster than the baseline

• 0.86X – Manually adding things to the dictionary but NOT setting a capacity is ~16% faster…

Okay, wait a second. Now we’re going to see that doing a dictionary copy is the FASTEST with a ~35% speed boost? I’m not sure how we’ve started to see known capacities not helping and copy constructors being fastest.

Even I’m skeptical now. So I wanted to rerun the benchmarks and I wanted to add a variant of each of the manual benchmarks that uses new() instead of an empty collection expression, [].

In this run of the benchmarks, things are much closer across the board. I don’t think that discredits the previous benchmarks, because truly many of them were also relatively close with the iterator copy constructor remaining the huge outlier. But the other huge outlier that remains is the copy constructor using another dictionary!

My takeaway is this:

• For the marginal boost in performance, I think you should opt for readability here — especially when the collection sizes are this small.

• If you know that you’re trying to set up a dictionary to be just like another, apparently copying it is much faster. So if you have this kind of thing on a hot path, here’s a fun little micro-optimization.

Are These Realistic Benchmarks?

I’ve written hundreds of articles, made hundreds of YouTube videos, and more posts across social media platforms than I could ever count. There will be people who want to pick these benchmarks apart, and unfortunately, their goal will seem like they’re just trying to discredit what’s being presented.

However, I DO think it’s important to discuss the context of the benchmarks and look at what’s being considered in these scenarios:

• In the grand scheme of things, I’d suspect it’s unlikely that you’re going to get huge performance gains from focusing on these collection initializers. There’s probably bigger fish to fry in your code. But we do see there are some gains to be had!

• When using an iterator example with a very small set of data or other very fast operations, the overhead of the iterator itself may dwarf some of the other actions taking place

• The use case for these different ways of creating lists varies. For some, we’re defining the full collection whereas for others we’re using values from another collection. The use case isn’t necessarily apples to apples for a comparison.

• There seem to be big gains from knowing the capacity up front, which is likely helping reduce collection resizing behind the scenes. How might this change if we were dealing with larger data sets?

The goal of presenting these benchmarks is not to tell you that you must do things a certain way — it’s simply to show you some interesting information. Even if you are hyper-focused on performance, you should benchmark and profile your own code! Don’t rely on my results here. Let these serve as a starting point that you might be able to tune things on your hot path that you didn’t realize.

What other considerations can you think of? Feel free to share in the comments — but be conversational, please.

Wrapping Up Collection Initializer Performance in C#

Overall, I consider most of what we see in this article on collection initializer performance in C# to be micro-optimizations — more than likely. I wouldn’t lose sleep over using one way over another, as long as you’re optimizing for readability and your profiling results don’t show you spending most of your time doing collection initialization. I hope that you got to have fun exploring this with me and see that if you’re ever curious you can go set up some simple benchmarks to experiment!

If you found this useful and you’re looking for more learning opportunities, consider subscribing to my free weekly software engineering newsletter and check out my free videos on YouTube! Meet other like-minded software engineers and join my Discord community!

Want More Dev Leader Content?

• Follow along on this platform if you haven’t already!

• Subscribe to my free weekly software engineering and dotnet-focused newsletter. I include exclusive articles and early access to videos:
  SUBSCRIBE FOR FREE

• Looking for courses? Check out my offerings:
  VIEW COURSES

• E-Books & other resources:
  VIEW RESOURCES

• Watch hundreds of full-length videos on my YouTube channel:
  VISIT CHANNEL

• Visit my website for hundreds of articles on various software engineering topics (including code snippets):
  VISIT WEBSITE

• Check out the repository with many code examples from my articles and videos on GitHub:
  VIEW REPOSITORY

Once you’ve got a feel for how collection initializers and collection expressions in C# work, you’ll be geared up to check out some of the performance benchmarks on them. There’s no point in hyper-optimizing for this stuff unless you understand the basics!

Using List<T> with Collection Initializers in C#

Collection initializers in C# allow for a concise and readable way to populate collections like List<T> upon instantiation. This feature simplifies code by enabling the initialization of a collection with a set of predefined elements without the need for multiple calls to the Add method.

These next subsections will show examples of collection initializers with the List<T> type. Keep in mind that the entire point of these initializers is to define collections with elements in them to start with, which would save us from doing something like the following:

List<string> devLeaderCoolList = new List<string>();
devLeaderCoolList.Add("Hello");
devLeaderCoolList.Add(", ");
devLeaderCoolList.Add("World!");

So with this as a starting point, consider that the upcoming examples make this feel more streamlined and concise.

Example 1: Initializing a List of Integers

List<int> primeNumbers = new List<int> { 2, 3, 5, 7, 11, 13, 17 };

This example demonstrates initializing a List<int> with a collection of prime numbers. The numbers are enclosed in braces {} and separated by commas, directly following the instantiation of the list.

We can also use a slightly more short-hand syntax to drop the entire duplicated type definition from the right side of the equal sign:

List<int> primeNumbers = new() { 2, 3, 5, 7, 11, 13, 17 };

Example 2: Combining Object and Collection Initializers

public class Student
{
    public string Name { get; set; }
    public int Age { get; set; }
}

List<Student> students = new List<Student>
{
    new Student { Name = "Alice", Age = 22 },
    new Student { Name = "Bob", Age = 24 }
};

Here, we combine object and collection initializers to create a List<Student> where each Student object is initialized with Name and Age properties. This approach streamlines the process of filling a collection with fully initialized objects. The important thing to pay attention to here is that the object initializer syntax is very much like the collection initializer syntax, but we are indeed doing two things:

1. Assigning values to properties of new objects

2. Assigning the collection elements upon collection creation

Example 3: Using Complex Expressions

List<double> areas = new List<double>
{
    Math.PI * Math.Pow(3, 2),
    Math.PI * Math.Pow(5, 2)
};

This example initializes a List<double> with areas of circles (using πr²), where r is the radius. It illustrates that expressions, including method calls, can be used within collection initializers — that is, there is no restriction on constants or pre-evaluated values.

Example 4: Nested Collection Initializers

public class Classroom
{
    public List<Student> Students { get; set; }
}

List<Classroom> classrooms = new List<Classroom>
{
    new Classroom
    {
        Students = new List<Student>
        {
            new Student { Name = "Alice", Age = 22 }
        }
    },
    new Classroom
    {
        Students = new List<Student>
        {
            new Student { Name = "Bob", Age = 24 }
        }
    }
};

This example shows how to use nested collection initializers to initialize a list of Classroom objects, each containing a list of Student objects. Very much like Example 2 that we looked at already, but this takes things up one more notch showing multiple collection initializers and object initialization as well.

Example 5: Simple List Initialization with Collection Expressions

In C# 11 we start to get some new fancier syntax for collection expressions. This was a step forward in reducing the verbosity of collection declarations using more shorthand similar to other languages. Microsoft says in their documentation:

You can use a collection expression to create common collection values. A collection expression is a terse syntax that, when evaluated, can be assigned to many different collection types. A collection expression contains a sequence of elements between [ and ] brackets.

Microsoft

Let’s check out an example:

List<int> evenNumbers = [2, 4, 6, 8, 10];

This example demonstrates the straightforward initialization of a List<int> using the new collection expressions syntax, making the code more concise and readable.

Example 6: Combining Collections with Spread Operator

And there are even more goodies in C# 12 — we get the spread operator for collection initialization:

List<int> firstBatch = [1, 2, 3];
List<int> combinedList = [0, ..firstBatch, 4];

Here, the spread operator .. is used to include elements from an existing collection (firstBatch) into a new list, showcasing the flexibility of the new syntax in combining collections seamlessly.

Where Are We Headed With These?

As you read through the various code examples, you can decide for yourself which ones offer you the readability that you prefer. There’s not necessarily a right or wrong answer here, but with variety and choice, we are likely going to need to make decisions within our teams about how to stay consistent. Try to strike a balance between minimizing redundancy without hiding too much type information!

But what’s next? Do we care THAT much about readability?

I mean, I do. Honestly, I think it’s incredibly important to prioritize readability in code. But if you’re curious like me, you might see a post like this from Dave Callan on the interwebs and get very curious:

And since this is what sparked my interest and caused me to write this article as a primer, you’ll perhaps be interested in the performance characteristics that I investigated!

Wrapping Up C# Collection Initializers and Collection Expressions

Now that you’ve seen various examples of the syntax that we have access to, you can make your own informed decisions about which are most readable to you. I think it’s always important to spend some time looking at alternatives so that you can understand different perspectives, even if it seems like it might be minor. Odds are you’re going to read and write collection initializers and collection expressions MANY times in your software engineering career — so why not optimize your choice?

Speaking of optimizations… wait until you see the next article on the performance of collection initializers!

If you found this useful and you’re looking for more learning opportunities, consider subscribing to my free weekly software engineering newsletter and check out my free videos on YouTube! Meet other like-minded software engineers and join my Discord community!

Want More Dev Leader Content?

• Follow along on this platform if you haven’t already!

• Subscribe to my free weekly software engineering and dotnet-focused newsletter. I include exclusive articles and early access to videos:
  SUBSCRIBE FOR FREE

• Looking for courses? Check out my offerings:
  VIEW COURSES

• E-Books & other resources:
  VIEW RESOURCES

• Watch hundreds of full-length videos on my YouTube channel:
  VISIT CHANNEL

• Visit my website for hundreds of articles on various software engineering topics (including code snippets):
  VISIT WEBSITE

• Check out the repository with many code examples from my articles and videos on GitHub:
  VIEW REPOSITORY