.NET Drip for 2026-11-01

You have a log statement inside a loop that runs thousands of times. The message is useful, but building it over and over can mean extra work and extra garbage for the collector.

The logging source generator can build that method for you at compile time.

Try It

Create a .NET 10 console app and add the console logger:

dotnet new console -n LoggerMessageDemo -f net10.0
cd LoggerMessageDemo
dotnet add package Microsoft.Extensions.Logging.Console

Replace Program.cs with this:

using Microsoft.Extensions.Logging;

using var loggerFactory = LoggerFactory.Create(builder =>
    builder.AddSimpleConsole());

ILogger logger = loggerFactory.CreateLogger("Worker");

for (var item = 1; item <= 3; item++)
{
    Log.ProcessedItem(logger, item);
}

public static partial class Log
{
    [LoggerMessage(
        EventId = 1,
        Level = LogLevel.Information,
        Message = "Processed item {ItemNumber}")]
    public static partial void ProcessedItem(
        ILogger logger, int itemNumber);
}

Run it:

dotnet run

The generator supplies the body of ProcessedItem during the build. You call it like an ordinary method, and the log message keeps its structured ItemNumber field.

What's the Catch?

The containing type and method need to be partial. The message template is fixed at compile time, so use regular logging when the message itself needs to be dynamic.

This is most useful for hot paths or logs you call often. For a one off startup message, plain logger.LogInformation is perfectly fine.

Key Takeaway

[LoggerMessage] gives you compile time generated logging code without giving up structured logs. Start with the log statements that run a lot. No need to turn every log into a ceremony.

Notable Links

.NET Rocks! - RockBot with Rocky Lhotka

Carl and Richard chat with Rocky Lhotka about RockBot, a cloud-native AI assistant built in .NET as a set of containerized services under Kubernetes to address security and control gaps in agent frameworks like OpenClaw and Hermes. In this podcast, Rocky shares practical patterns for granting an agent safe, auditable access to calendar and email, and explains how an enterprise-style architecture can run off-cloud while staying cloud ready.

Are C# Pipeline Stages Parallel? Throughput, Ordering, and Benchmarks

Nick breaks down why C# pipeline stages are not inherently parallel and why await does not magically make them concurrent. In this post you get five execution models and a lightweight .NET 10 harness to measure throughput and latency, surface bottlenecks, and understand the real cost of ordering and capacity so you can pick a simpler model with confidence.

Run Local Akka.NET Clusters with Aspire

Aaron Stannard rolls out first-party .NET Aspire support for Akka.NET and shows how the new Akka.Aspire.Hosting and Akka.Aspire packages make multi-node clusters easy to run and debug locally. In this post, you get a practical recipe for declaring an executable topology with AppHost, plugging in Redis or Azure Table Storage discovery, and letting cluster bootstrap plus health checks do the heavy lifting.

XAML.io Adds Full Coding Agent

XAML.io 0.9 brings a full coding agent that turns a plain English prompt into a running C#/XAML app in your browser so you can go from idea to app without wrestling a toolchain. This post shows how that flow still lands you in familiar territory with WebAssembly previews, NuGet, WPF-to-Web assist, and download-ready .NET 10 solutions for Visual Studio.

Run temporary containers in .NET tests withMeziantou.Framework.TemporaryContainers

Gérald Barré shows how to run real dependencies in .NET integration tests with Meziantou.Framework.TemporaryContainers, a small API that manages short-lived containers across Docker, Podman, Apple container, and WSL. This post highlights smart runtime auto detection, simple wait strategies, reusable containers, and built-in database helpers so your tests stay reliable and portable.

How to Accelerate Visual Studio 2026 Build Times - Parallel MSBuild and LocalCaching Guide

Kunal Chowdhury shows how to slash Visual Studio 2026 build times on large .NET solutions by tuning parallel out-of-process MSBuild, turning on content-addressable local caches, and skipping needless downstream rebuilds via public API checks. With smart hardware tips and a quick way to validate results in MSBuild logs, this post targets inner-loop gains that often land in the 45 to 65 percent range.

Easier to read in your browser?

You can find this issue at https://dotnetdrip.com/archive/2026-11-01/.