DEV Community: Anton Grebenkin

The Hidden Behavior of C# Records

Anton Grebenkin — Tue, 05 Aug 2025 11:48:17 +0000

C# records, introduced in C# 9, have become a favorite among developers for creating immutable data-transfer objects. Their concise syntax for defining properties, along with built-in value equality and a ToString() override, simplifies a lot of boilerplate code. One of their most celebrated features is the with expression, which allows for "nondestructive mutation"—creating a copy of a record with some properties changed.

However, there's a subtle but critical behavior related to the with expression that can easily catch developers by surprise: properties that are initialized from other primary constructor parameters are not recalculated when you create a copy using with.

The Seemingly Simple Scenario

Let's consider a common use case: a Person record that has a FirstName, a LastName, and a FullName property derived from the other two. A developer might intuitively write it like this:

public record Person(string FirstName, string LastName)
{
    // This property is calculated ONCE during construction.
    public string FullName { get; } = $"{FirstName} {LastName}";
}

This looks perfectly reasonable. When we create a new Person, the FullName property is correctly initialized.

var person1 = new Person("John", "Doe");

// Outputs: FirstName: John, LastName: Doe, FullName: John Doe
Console.WriteLine($"FirstName: {person1.FirstName}, LastName: {person1.LastName}, FullName: {person1.FullName}");

The problem arises when we use the with expression to create a modified copy. What would you expect the FullName to be in the following code?

var person2 = person1 with { FirstName = "Jane" };

// What will this output?
Console.WriteLine($"FirstName: {person2.FirstName}, LastName: {person2.LastName}, FullName: {person2.FullName}");

Many developers would expect the output to be FirstName: Jane, LastName: Doe, FullName: Jane Doe. After all, we changed the FirstName, so the FullName should update accordingly.

The actual output is:

FirstName: Jane, LastName: Doe, FullName: John Doe

The FullName was not recalculated. It retained the value from the original person1 object.

Why Does This Happen? The Mechanics of `with`

The root cause lies in how the with expression is implemented by the C# compiler. Under the hood, a with expression is syntactic sugar for a method call that performs a shallow, member-wise copy.

When you define a record, the compiler generates a hidden copy constructor. This constructor is what the with expression uses as its foundation. Conceptually, it looks something like this:

// This is a simplified, conceptual representation of what the compiler generates
protected Person(Person original)
{
    this.FirstName = original.FirstName;
    this.LastName = original.LastName;
    this.FullName = original.FullName; // <-- The crucial line
}

The key insight is that the copy constructor copies the values from the backing fields of the original object. In our example, person1 had its FullName backing field initialized to "John Doe". The copy constructor simply copied that string value over to the new instance. It does not re-execute the property initializer (= $"{FirstName} {LastName}"). The property initializer is only executed when the primary constructor is called directly, not when the copy constructor is used.

After the shallow copy is complete, the with expression then assigns the new value for FirstName, but by then it's too late for FullName.

The Solution: Use a True Computed Property

To achieve the expected behavior where a derived property is always up-to-date, you must define it as a true computed property using an expression-bodied member (often called a "fat arrow" property).

Here is the corrected version of the Person record:

public record Person(string FirstName, string LastName)
{
    // This is a computed property. It is re-evaluated on every access.
    public string FullName => $"{FirstName} {LastName}";
}

The key difference is the use of => instead of { get; } =. An expression-bodied property does not have a backing field. Instead, it is essentially a method that is executed every single time the property is accessed.

Now, if we run the same test code with this new record definition:

var person1 = new Person("John", "Doe");
var person2 = person1 with { FirstName = "Jane" };

// Now, this produces the expected result
Console.WriteLine($"FirstName: {person2.FirstName}, LastName: {person2.LastName}, FullName: {person2.FullName}");

The output will be correct:

FirstName: Jane, LastName: Doe, FullName: Jane Doe

This works because when we access person2.FullName, the code $"{FirstName} {LastName}" is executed in the context of person2, using its current property values.

Conclusion

The with expression is a powerful tool for working with immutable data, but it's vital to understand its mechanics. Remember this key distinction:

Property with an initializer (public string Prop { get; } = ...): The value is calculated once during initial construction and is copied as-is by the with expression.
Computed property (public string Prop => ...): The value is calculated on every access and will always reflect the current state of the object, making it the correct choice for derived values that must stay in sync.

FlashEvents: A Free, Simple Alternative to MediatR Notification Publisher

Anton Grebenkin — Mon, 14 Jul 2025 10:49:10 +0000

The Situation

Let's be honest, many of us in the .NET world have relied on MediatR. It's a fantastic library that has shaped how we think about CQRS and in-process messaging. However, with the recent introduction of a licensing model, many developers are looking for free, open-source alternatives for its notification (publish/subscribe) capabilities.

I was in the same boat. I love the pub/sub pattern for decoupling components, but I needed a solution that was not only free but also incredibly fast and architecturally sound, especially for applications using services with specific lifetimes, like Entity Framework's DbContext.

That's why I created FlashEvents.

FlashEvents is a high-performance, in-memory event publishing library for .NET designed with two core principles in mind: simplicity and speed.

What Makes FlashEvents Different?

FlashEvents focuses exclusively on the "notification" or "event publishing" part of the pattern. Its key features are designed to solve common problems gracefully:

🚀 Blazing Fast Performance: It's optimized for low-latency and minimal memory allocations. (We'll get to the benchmarks later!)
⚡ Parallel Execution by Default: When you publish an event, all its handlers run concurrently using Task.WhenAll. This maximizes throughput without any special configuration.
🛡️ Scoped Handler Isolation: This is the killer feature. Each event handler is resolved and executed in its own IServiceScope. This completely prevents issues with shared state. If one handler uses a DbContext, it gets its own instance. Another handler can use its own DbContext or other scoped services without any conflicts. This is a huge win for reliability.
🔧 Simple & Fluent API: Setting it up is a breeze with clean dependency injection extensions.
🔍 Automatic Handler Discovery: A single line of code can register all your event handlers from an assembly.

Let's See It in Action

Here’s how you can integrate FlashEvents into your project in just a few minutes.

1. Define Your Event

using FlashEvents.Abstractions;

public record OrderCreatedEvent(int OrderId, string CustomerEmail) : IEvent;

2. Create Event Handlers

using FlashEvents.Abstractions;

// Handler 1: Sends a welcome email
public class SendWelcomeEmailHandler : IEventHandler<OrderCreatedEvent>
{
    private readonly IEmailService _emailService; // Can be transient or singleton

    public SendWelcomeEmailHandler(IEmailService emailService) { /* ... */ }

    public async Task Handle(OrderCreatedEvent @event, CancellationToken ct)
    {
        // ... send email ...
    }
}

// Handler 2: Updates analytics using a scoped service
public class UpdateAnalyticsHandler : IEventHandler<OrderCreatedEvent>
{
    private readonly IAnalyticsService _analyticsService; // Scoped service

    public UpdateAnalyticsHandler(IAnalyticsService analyticsService) { /* ... */ }

    public async Task Handle(OrderCreatedEvent @event, CancellationToken ct)
    {
        // ... update analytics ...
    }
}

3. Configure Dependency Injection

using FlashEvents;
using System.Reflection;

var builder = WebApplication.CreateBuilder(args);

// 1. Add FlashEvents services
builder.Services.AddEventPublisher();

// 2. Automatically discover and register all handlers
builder.Services.AddEventHandlersFromAssembly(Assembly.GetExecutingAssembly());

// 3. Register your other application services
builder.Services.AddTransient<IEmailService, EmailService>();
builder.Services.AddScoped<IanalyticsService, AnalyticsService>(); // Our scoped service

var app = builder.Build();

// ...

4. Publish an Event

using FlashEvents.Abstractions;
using Microsoft.AspNetCore.Mvc;

[ApiController]
[Route("[controller]")]
public class OrdersController : ControllerBase
{
    private readonly IEventPublisher _eventPublisher;

    public OrdersController(IEventPublisher eventPublisher)
    {
        _eventPublisher = eventPublisher;
    }

    [HttpPost]
    public async Task<IActionResult> CreateOrder()
    {
        // ... logic to create an order ...
        var orderEvent = new OrderCreatedEvent(123, "test@example.com");

        // Publish it. FlashEvents handles the rest.
        await _eventPublisher.PublishAsync(orderEvent);

        return Ok("Order created and events are being handled.");
    }
}

But Is It Fast? The Benchmarks

Talk is cheap. Let's look at the numbers against MediatR v12.5.0.

System: i5-13400F, .NET 8

Scenario 1: Single Handler (vs. MediatR's Parallel Publisher)

Method	Mean	Error	StdDev	Ratio	Allocated	Alloc Ratio
FlashEvents_Publish	205.1 ns	1.79 ns	1.68 ns	1.00	520 B	1.00
MediatR_Publish	141.19 ns	1.114 ns	0.988 ns	1.55	664 B	3.77

Scenario 2: Two Handlers (vs. MediatR's Parallel Publisher)

This test highlights the parallel execution for two handlers.

Method	Mean	Error	StdDev	Ratio	Allocated	Alloc Ratio
FlashEvents_Publish	269.3 ns	3.34 ns	2.79 ns	1.00	712 B	1.00
MediatR_Publish	171.4 ns	0.95 ns	0.79 ns	0.64	824 B	1.16

Why Choose FlashEvents?

If you need the request/response or pipeline behaviors from MediatR, then MediatR is still the tool for the job.

But if you are primarily using its notification publisher feature, FlashEvents offers a compelling alternative:

Free & Open Source: It's licensed under MIT. No fees, no strings attached.
Architectural Safety: Built-in scoped execution for handlers is a huge advantage that prevents a common class of bugs related to dependency lifetimes.
Simplicity: It does one thing and does it well. The API surface is minimal and easy to learn.
Performance: It's extremely lightweight and holds its own against the industry standard, especially regarding memory allocations.

Give It a Try!

I built FlashEvents to solve a problem I was facing, and I hope it can help you too. It's available on NuGet, and the source code is on GitHub.

NuGet Package: FlashEvents
GitHub Repo: Anton-Grebenkin/FlashEvents