DEV Community: dotnet

StructoFox: Flowcharts->structograms->code

Doombug75 — Thu, 16 Jul 2026 18:37:19 +0000

I made a small tool for planning code as diagrams instead of writing it top-down, and just put out the first build.

It makes it easy to quickly create flowcharts, and put them into multi format .pdfs, .tifs or just images for your presentations.
Code functionality: let the tool automatically turn the Flowcharts into structograms, which can easily be turned into a code skeleton in 13 languages - without any AI.
Or you can activate the optional AI plugin (included and also Oppen-Source), connect API or local (llm/ollama) models, and let those generate code in whole projects.

The conversion from chart to structogram can also act as a structure check — jumps that can't be expressed as clean nested blocks get flagged instead of silently miscompiled.

It's .NET 10 + Avalonia, runs on Windows/Linux/macOS, MIT licensed. Beta phase, planned features all work and known bugs are fixed.

Repo: https://github.com/StructoFox/StructoFox

If you find some real bugs, let me know. This was made for all those who teach or learn flowcharts and structograms, and for all those who simply want to print out the one or other huge colorful flowchart. :o)

Have fun!

Asdamir: Scaffold a working .NET 10 + Blazor enterprise app in 2 commands

Orhan özşahin — Thu, 16 Jul 2026 18:18:31 +0000

I've been building Asdamir for the past several months — a CLI + framework that scaffolds production-shaped .NET apps. Just shipped 1.3, so I'm writing it up.

What it does

asdamir new app MyApp --mode free gives you a working Blazor Server + API app with:

Authentication + RBAC
Menus and navigation
Localization (tr/en/ru)
A journaled migration runner

It creates the database, applies migrations, and writes the dev secrets — then ./restart-myapp.sh and you're logged in. No manual wiring.

Adding a feature is one command

asdamir new feature Product --fields "Name:string,Price:decimal,Stock:int"

That gives you: entity + CRUD page + menu entry + permissions + migration — applied automatically. Restart the app and the page is in the menu.

Full quick-start

# install the CLI (once)
dotnet tool install -g Asdamir.Tools

# create an app in any empty directory
mkdir my-apps && cd my-apps
asdamir new app DemoApp --mode free

# run it
cd DemoApp && ./restart-demoapp.sh
# → https://localhost:7010, sign in with the starter admin

# add a feature
asdamir new feature Product --fields "Name:string,Price:decimal,Stock:int"
./restart-demoapp.sh

Prerequisites: .NET 10 SDK + SQL Server (localhost:1433).

Free mode is genuinely standalone

No license check, no control plane, no phone-home. The generated app owns its own database and issues its own JWTs. It's open-core on NuGet:

Asdamir.Core — models, multi-tenancy, JWT/AES-GCM, validation
Asdamir.Data — Dapper repositories, journaled migrations, outbox
Asdamir.Web — Blazor components, security middleware (CSP nonce, rate-limit), localization
Asdamir.Payments — Paddle (MoR) + crypto rails, webhook signature verification
Asdamir.Tools — the CLI

There's a commercial control plane (multi-app RBAC/config/monitoring) but you never need it for a single app.

Why I built it

I've been doing enterprise .NET for ~20 years, and this came out of rebuilding the same auth/RBAC/menu/i18n plumbing on project after project. Every new app started with the same two weeks of boilerplate. Asdamir is that boilerplate, generated in two commands.

I'd love feedback

Does the free-mode flow actually work on your machine?
Is the scaffolding opinionated in useful ways, or annoying ways?
What would stop you from using it on a real project?

Site: asdamir.com · Docs: docs.asdamir.com · GitHub: asdamir-framework/asdamir

Happy to answer anything in the comments.

Design Patterns in C# Part 2: Structural Patterns - Adapter, Decorator, Facade, and Composite

Manohari Jayachandran — Thu, 16 Jul 2026 15:14:32 +0000

This is Part 2 of a three-part design patterns series built for interview prep. Part 1 covered Creational patterns - how objects get created. This part covers Structural patterns - how objects and classes are composed into larger structures. Same format throughout: the problem each pattern solves, an analogy, a before-and-after code example, and honest guidance on when it's actually worth the added complexity.

Structural patterns include Adapter, Decorator, Facade, Composite, Proxy, and Bridge. This post covers the four that come up most often in real interviews and real code: Adapter, Decorator, Facade, and Composite.

Pattern 1: Adapter

The problem Adapter solves is making two interfaces that were never designed to work together actually work together, without modifying either one.

Think of a physical power plug adapter. A US laptop charger and a European wall socket are both perfectly functional on their own, but their shapes are incompatible. Nobody rewires the wall or rebuilds the charger - a small adapter sits between them, translating one shape into the other. Adapter does the same thing in code: it translates one interface into another without changing either side.

// The interface your code already expects
public interface IPaymentProcessor
{
    void ProcessPayment(decimal amount);
}

// A third-party library with an incompatible interface
// you cannot modify - this is someone else's code
public class LegacyPaymentGateway
{
    public void MakeTransaction(double amountInCents)
    {
        Console.WriteLine($"Processing {amountInCents} cents");
    }
}

// WITHOUT Adapter - the rest of the codebase has to
// know about LegacyPaymentGateway's specific method
// signature and unit conventions directly
public class CheckoutService
{
    private readonly LegacyPaymentGateway _gateway = new();

    public void Checkout(decimal amount)
    {
        // every caller needs to remember to convert
        // dollars to cents, and call MakeTransaction
        // specifically - tightly coupled to this one
        // library's exact shape
        _gateway.MakeTransaction((double)(amount * 100));
    }
}

// WITH Adapter - the incompatibility is isolated
// to one small class
public class LegacyPaymentAdapter : IPaymentProcessor
{
    private readonly LegacyPaymentGateway _gateway;

    public LegacyPaymentAdapter(LegacyPaymentGateway gateway)
        => _gateway = gateway;

    public void ProcessPayment(decimal amount)
    {
        // the unit conversion and method name
        // mismatch lives HERE, in exactly one place
        double amountInCents = (double)(amount * 100);
        _gateway.MakeTransaction(amountInCents);
    }
}

// The rest of the codebase depends only on
// IPaymentProcessor - it never knows LegacyPaymentGateway
// exists at all
public class CheckoutService
{
    private readonly IPaymentProcessor _processor;

    public CheckoutService(IPaymentProcessor processor)
        => _processor = processor;

    public void Checkout(decimal amount)
        => _processor.ProcessPayment(amount);
}

var adapter = new LegacyPaymentAdapter(new LegacyPaymentGateway());
var checkout = new CheckoutService(adapter);
checkout.Checkout(49.99m);

Adapter earns its place specifically around third-party libraries, legacy code, or any external dependency whose interface doesn't match what the rest of the codebase expects and can't be changed directly. It's not worth introducing between two pieces of code that are both already under direct control - in that case, simply changing one interface to match the other is the more direct fix, with no adapter layer needed at all.

Pattern 2: Decorator

The problem Decorator solves is adding behavior to a single object instance dynamically, without modifying its class, without affecting other instances of that same class, and without relying on subclassing.

Think of a plain coffee, with milk added, then a shot of caramel added on top of that. Each addition wraps the drink before it, adding its own contribution, without needing a separate class for every possible combination - CoffeeWithMilk, CoffeeWithCaramel, CoffeeWithMilkAndCaramel, and so on infinitely. Decorator wraps objects the same way, layer by layer, at runtime.

// The base interface
public interface ICoffee
{
    decimal Cost();
    string Description();
}

public class PlainCoffee : ICoffee
{
    public decimal Cost() => 2.00m;
    public string Description() => "Coffee";
}

// WITHOUT Decorator - a new subclass for every
// possible combination of add-ons
public class CoffeeWithMilk : PlainCoffee { /* ... */ }
public class CoffeeWithCaramel : PlainCoffee { /* ... */ }
public class CoffeeWithMilkAndCaramel : PlainCoffee { /* ... */ }
// Adding a third add-on option means the number of
// subclasses needed grows combinatorially

// WITH Decorator - each add-on is a small wrapper
// class that can be combined at runtime, in any order
public abstract class CoffeeDecorator : ICoffee
{
    protected readonly ICoffee _coffee;
    protected CoffeeDecorator(ICoffee coffee)
        => _coffee = coffee;

    public virtual decimal Cost() => _coffee.Cost();
    public virtual string Description()
        => _coffee.Description();
}

public class MilkDecorator : CoffeeDecorator
{
    public MilkDecorator(ICoffee coffee) : base(coffee) { }

    public override decimal Cost() => _coffee.Cost() + 0.50m;
    public override string Description()
        => _coffee.Description() + " + milk";
}

public class CaramelDecorator : CoffeeDecorator
{
    public CaramelDecorator(ICoffee coffee) : base(coffee) { }

    public override decimal Cost() => _coffee.Cost() + 0.75m;
    public override string Description()
        => _coffee.Description() + " + caramel";
}

// Combine any way, at runtime, without a single
// new subclass for the combination
ICoffee order = new CaramelDecorator(
    new MilkDecorator(new PlainCoffee())
);

Console.WriteLine(order.Description()); // Coffee + milk + caramel
Console.WriteLine(order.Cost());        // 3.25

This pattern is not just a textbook exercise - it's how the .NET Stream classes actually work. new GZipStream(new FileStream(path, FileMode.Open), CompressionMode.Compress) wraps a FileStream with compression behavior, and more decorators like encryption or buffering can wrap that further, each layer adding one capability without changing any of the classes underneath.

Decorator earns its place when behavior needs to be added or removed from individual object instances at runtime, in combinations that would otherwise require an unmanageable number of subclasses. For a fixed, small set of variations known entirely at compile time, straightforward inheritance or simple composition without the full decorator pattern is often simpler and easier to follow.

Pattern 3: Facade

The problem Facade solves is providing one simple, unified interface to a subsystem made up of many complex, interacting parts, so calling code doesn't need to understand or coordinate all of those parts directly.

Think of a car's ignition. Turning the key, or pressing the start button, triggers fuel injection, spark timing, starter motor engagement, and a dozen other coordinated subsystems - the driver never manages any of that directly. One simple action hides a genuinely complicated system underneath. Facade provides that same single, simple entry point in code.

// A genuinely complex subsystem with several
// interacting parts - this complexity is real
// and does not go away, it just gets hidden
public class InventorySystem
{
    public bool CheckStock(string sku, int qty)
        => true; // simplified
}

public class PaymentSystem
{
    public bool ChargeCard(string cardToken, decimal amount)
        => true; // simplified
}

public class ShippingSystem
{
    public string ScheduleDelivery(string address)
        => "TRACK123"; // simplified
}

public class NotificationSystem
{
    public void SendConfirmation(string email, string trackingNumber)
        => Console.WriteLine($"Confirmation sent: {trackingNumber}");
}

// WITHOUT Facade - calling code has to know about
// and correctly coordinate all four systems itself
public void PlaceOrderWithoutFacade(
    string sku, int qty, string cardToken,
    decimal amount, string address, string email)
{
    var inventory = new InventorySystem();
    var payment = new PaymentSystem();
    var shipping = new ShippingSystem();
    var notification = new NotificationSystem();

    if (inventory.CheckStock(sku, qty))
    {
        if (payment.ChargeCard(cardToken, amount))
        {
            var tracking = shipping.ScheduleDelivery(address);
            notification.SendConfirmation(email, tracking);
        }
    }
    // this coordination logic now has to be repeated
    // correctly everywhere an order gets placed
}

// WITH Facade - one simple entry point
public class OrderFacade
{
    private readonly InventorySystem _inventory = new();
    private readonly PaymentSystem _payment = new();
    private readonly ShippingSystem _shipping = new();
    private readonly NotificationSystem _notification = new();

    public bool PlaceOrder(
        string sku, int qty, string cardToken,
        decimal amount, string address, string email)
    {
        if (!_inventory.CheckStock(sku, qty))
            return false;

        if (!_payment.ChargeCard(cardToken, amount))
            return false;

        var tracking = _shipping.ScheduleDelivery(address);
        _notification.SendConfirmation(email, tracking);
        return true;
    }
}

// Calling code is now trivially simple, and the
// coordination logic exists in exactly one place
var facade = new OrderFacade();
facade.PlaceOrder("SKU-001", 1, "tok_abc", 49.99m,
    "123 Main St", "customer@example.com");

Facade earns its place whenever calling code repeatedly needs to coordinate several subsystems in the same sequence - centralizing that coordination in one place prevents the same multi-step logic from being duplicated, and inevitably drifting out of sync, across multiple call sites. It's not about making the underlying subsystem less complex - that complexity is still there - it's about giving callers a simple, correct way to use it without needing to understand all of it directly.

Pattern 4: Composite

The problem Composite solves is treating a single object and a group of objects through the exact same interface, so calling code doesn't need separate logic for "one item" versus "a collection of items."

Think of a file system. A folder can contain files, and it can also contain other folders, which themselves contain files or more folders, arbitrarily deep. When calculating how much space a folder uses, the calculation works identically whether a given item turns out to be a single file or an entire nested folder - each one just needs to be able to answer "how big are you." Composite is exactly this: treating individual objects and groups of objects through one shared interface.

// The shared interface - both leaves and
// composites implement this
public interface IFileSystemItem
{
    string Name { get; }
    long GetSize();
}

// Leaf - a single file, no children
public class FileItem : IFileSystemItem
{
    public string Name { get; }
    private readonly long _size;

    public FileItem(string name, long size)
    {
        Name = name;
        _size = size;
    }

    public long GetSize() => _size;
}

// Composite - a folder, which can contain
// other IFileSystemItems (files OR folders)
public class FolderItem : IFileSystemItem
{
    public string Name { get; }
    private readonly List<IFileSystemItem> _children = new();

    public FolderItem(string name) => Name = name;

    public void Add(IFileSystemItem item)
        => _children.Add(item);

    // The size of a folder is just the sum of
    // whatever its children report - it does not
    // matter whether each child is a file or
    // another folder, the interface is identical
    public long GetSize()
        => _children.Sum(child => child.GetSize());
}

// Building a nested structure
var root = new FolderItem("root");
var docs = new FolderItem("documents");
docs.Add(new FileItem("resume.pdf", 500));
docs.Add(new FileItem("cover-letter.pdf", 200));

var photos = new FolderItem("photos");
photos.Add(new FileItem("vacation.jpg", 3000));

root.Add(docs);
root.Add(photos);
root.Add(new FileItem("notes.txt", 50));

// One call, correctly recurses through the ENTIRE
// nested structure - no special-casing files vs
// folders anywhere in this calling code
Console.WriteLine(root.GetSize()); // 3750

Composite earns its place specifically when a domain is genuinely hierarchical - things that contain other things of the same conceptual type, arbitrarily deep - like file systems, UI component trees, or organizational charts. For a flat, non-nested collection of items with no "contains other items of the same type" relationship, Composite adds a layer of abstraction that isn't solving any real problem, and a plain list is simpler and more honest about the actual shape of the data.

Key Lessons

Adapter isolates an incompatibility to one small class, and earns its place specifically around external dependencies that can't be modified directly - not between two pieces of code already under direct control.

Decorator adds behavior to individual object instances at runtime, avoiding a combinatorial explosion of subclasses - .NET's own Stream classes are a real, built-in example of this pattern in daily use.

Facade centralizes coordination logic for a complex subsystem into one simple entry point, without making the underlying subsystem itself any less complex.

Composite lets calling code treat a single item and a nested group of items identically, and earns its place specifically for genuinely hierarchical domains, not for flat collections with no real containment relationship.

Every structural pattern covered here is solving a coupling or duplication problem that becomes real friction at some scale - none of them should be reached for preemptively before that friction actually shows up.

What's Next

Part 3 covers Behavioral patterns - Strategy, Observer, Command, State, and Template Method - the patterns concerned with how objects communicate and share responsibility with each other. This closes out the series.

Summary

Structural patterns solve one consistent underlying question - how should these pieces actually fit together - in four different ways depending on the specific shape of the problem. Adapter reconciles two incompatible interfaces. Decorator adds behavior to individual instances without subclass explosion. Facade simplifies the calling code's relationship to a complex subsystem. Composite treats individual items and nested groups through one shared interface. As with the creational patterns covered in Part 1, each of these adds real indirection that only pays for itself once the specific problem it solves is genuinely present in the code.

Originally published at TechStack Blog: https://www.techstackblog.com/post.html?slug=design-patterns-structural-csharp

Part 1 of this series (Creational patterns): https://www.techstackblog.com/post.html?slug=design-patterns-creational-csharp

More from TechStack Blog: CS Fundamentals: https://www.techstackblog.com/category.html?cat=cs-fundamentals
C# / .NET: https://www.techstackblog.com/category.html?cat=csharp

v0.2.0 - Horus.F5Tts.Onnx - MASSIVE improvements

Kasper — Thu, 16 Jul 2026 14:26:20 +0000

HORUS.F5TTS.ONNX
HORUS.F5TTS.ONNX - NuGet

v0.2.0 ships FP16 → 10× faster on GPU.
60 ms per denoising step, down from 617. Measured, not vibes.

Plus: text of any length, real cancellation, resampling built in.

MIT · 90 tests
dotnet add package Horus.F5Tts.Onnx

The 8-Byte Lock: Packing a Reader-Writer Lock Into 64 Bits

Loïc Baumann — Thu, 16 Jul 2026 14:01:20 +0000

💡Typhon is an embedded, persistent, ACID database engine written in .NET that speaks the native language of game servers and real-time simulations: entities, components, and systems.

It delivers full transactional safety with MVCC snapshot isolation at sub-microsecond latency, powered by cache-line-aware storage, zero-copy access, and configurable durability.

Series: A Database That Thinks Like a Game Engine

Why I'm Building a Database Engine in C#

What Game Engines Know About Data That Databases Forgot

Microsecond Latency in a Managed Language

Deadlock-Free by Construction

Three Durability Modes, One WAL

Building a Page Cache That Doesn't Count

MVCC at Microsecond Scale

The 8-Byte Lock (this post)

Why We Eliminated the Primary Key B+Tree (coming soon)

GitHub repo • 📬 Subscribe via RSS

A reader-writer lock has a lot to keep track of. How many readers are inside right now. How many are queued at the door. How many writers are queued behind them. Which thread, exactly, is holding it exclusively — because releasing a lock you don't own is a bug you want to catch loudly. Whether anyone has ever had to wait on it, so you can find your hot spots later.

In .NET the reflex answer is ReaderWriterLockSlim. It tracks all of that for you, and it costs you a heap object with a header, a sync block, an internal wait queue, and a call into the kernel when things get tense.

Typhon's answer is a ulong. All of it — the counter, the three classes of waiter, the owning thread id, the contention flag, the state machine — lives in eight bytes, and every state transition is exactly one CompareExchange. Uncontended, it costs 19 nanoseconds.

This post is the bit layout, the pattern that makes it readable instead of a swamp of shifts and masks, the fairness ladder that stops readers from starving writers, and an honest accounting of the parts I got wrong. And it ends on the trade that actually decides which lock goes where: every feature in that word is paid for in bits — and when the lock lives inside a page that gets written to disk, bits are a great deal more expensive than they look.

📍 Where we are

The last post built revision chains — the per-component version lists that give every transaction its own frozen snapshot of the database. Chains get appended to while other threads are walking them, so something has to arbitrate. I waved at it and moved on: "a small reader-writer lock in the header." This is that lock, and its smaller sibling.

And it connects to Deadlock-Free by Construction, which made a strong claim: Typhon has no deadlock detector because it holds no data locks across operations. That's still true. But "no data locks" doesn't mean "no locks" — it means the locks that remain are short, physical, and local: a latch on a page while you read its header, a latch on a chain while you splice a revision into it. Held for tens of nanoseconds, never across a wait, never two at once in an order that could cycle. Those latches are what this post is about, and their size is the whole design constraint.

🔒 Why not just use the lock in the box?

Steel-manning first: ReaderWriterLockSlim is a good general-purpose lock, and if you need a handful of them you should use it. The trouble is what "a handful" means here.

Typhon needs a latch on every page in the page cache. Every block chain in every allocator. Every archetype cluster. Every component table. That's not a handful — in a database with a few gigabytes resident, that's hundreds of thousands of locks, each one guarding a critical section that lasts about as long as a cache miss.

At that multiplicity, three things about the standard answer become disqualifying:

Allocation. Monitor inflates a sync block per object; the modern System.Threading.Lock that the lock statement now prefers is itself a class, and so is ReaderWriterLockSlim — a heap object with a header, plus internal wait-queue machinery. Whichever you pick, you get an object. But a lock that must be a field inside a page header, sitting in a memory-mapped file, cannot be an object at all. It has to be a value you can embed.

Size. Even if you could embed it, sixty-odd bytes of lock inside a page header you were trying to keep to a cache line is a non-starter. The lock has to be an incidental cost of the structure, not a dominant one.

The floor. Typhon's cost model has a hierarchy, each rung roughly ten times the last:

Level	What it is	Cost
0	Thread-local read	~2 ns
1	Uncontended atomic (CAS)	~5–10 ns
2	Contended atomic, true sharing	20–140 ns
3	System call	~500–1,000 ns
4	Context switch / blocking lock	~10,000 ns
5	Thread oversubscription	100,000+ ns

A lock that blocks is a lock that can cost you Level 4. Ten microseconds, to protect a critical section that was going to last fifty nanoseconds — a 200× overhead on the thing you were trying to make fast. In a database targeting microsecond transactions, that single fact drives the whole design: stay on rungs 1 and 2, never touch rung 4 if the work is short enough to spin through.

So the requirement is a lock that is a plain value type, small enough to embed by the hundred-thousand, that transitions with atomics and never enters the kernel on the happy path. Nothing in the box does that. You have to build it.

🧩 What fits in sixty-four bits

AccessControl is one field — private ulong _data — carved up like this:

//  8  Shared usage counter   (bits 0-7)     up to 255 concurrent readers
//  8  Shared waiters         (bits 8-15)
//  8  Exclusive waiters      (bits 16-23)
//  8  Promoter waiters       (bits 24-31)
// 16  Exclusive thread id    (bits 32-47)
//  1  Contention flag        (bit 48)       sticky
// 13  Reserved               (bits 49-61)
//  2  State                  (bits 62-63)   Idle | Shared | Exclusive

Two design choices in there are worth pulling out.

Three separate waiter counters, not one. Readers waiting, writers waiting, and promoters waiting (a promoter is a thread that already holds shared access and wants to upgrade to exclusive) each get their own byte. That looks like a luxury until you see what it buys, which is the next section.

A sticky contention bit. Bit 48 is set — with a single atomic OR — the first time any thread has to wait on this lock, and it's never cleared until Reset(). The fast path never reads it. It costs nothing to carry, and it means that at any later moment I can sweep every page in the cache and ask which of these locks has ever been contended, even once — a free, permanent, per-lock hot-spot map. It's the cheapest profiling I have anywhere in the engine: one bit, set at most once, read only by tooling.

🧵 Why the thread id is exactly sixteen bits

The owning thread gets sixteen bits, and the field earns its keep: releasing an exclusive lock you don't own is a protocol violation, and I want it to throw rather than quietly corrupt the word. But a fixed-width thread id invites the obvious question — what happens when you run out?

Nothing, and the reason is exactly why Environment.CurrentManagedThreadId exists separately from the OS thread id in the first place. The OS id is a sparse, opaque handle whose reuse is nobody's contract. The managed id is deliberately the opposite: the runtime hands out the lowest available number, and a dead thread's id goes straight back into the pool. Ids stay dense and small — they count the threads alive right now, not the threads that have ever existed.

That inverts the constraint, and it's the whole reason sixteen bits is enough. Monotonic ids would make the field a lifetime budget: hand out 65,535 of them over the life of the process and the next thread wraps into someone else's identity. Recycled ids make it a concurrency ceiling instead — 65,535 threads alive at the same instant. A server that churns through millions of threads over a week never moves that ceiling; it just keeps handing out the same low numbers. And 65,535 simultaneously-live threads inside an embedded database engine isn't a limit to design around, it's a diagnosis: if you're there, the lock word is the least of your problems.

(It started at ten bits, which was a mistake — 1,024 is fine on a laptop and nonsense on a 512-core server.)

⚠️ The dependency I'm taking on, stated out loud. Lowest-available reuse is what the open-source runtime does; it is not what the runtime promises. No specification obliges ManagedThreadId to stay dense. I'm relying on an implementation detail, on purpose, and the reason I sleep at night is that the property is load-bearing for everybody who indexes anything by thread id — which is a lot of code, including the runtime's own. The incentive to preserve it is enormous and the incentive to break it is zero. But an assumption you've reasoned about and written down is a design decision; the same assumption left implicit is a landmine. So: written down.

💎 The prettiest code in the engine

Here's the problem with packing a lock into a word: the code turns into a swamp. Every operation becomes shift-mask-or-shift-back, and one misplaced & is a corruption bug that shows up as a hang under load three weeks later.

The fix is LockData — a ref struct that makes the word behave like an object while still committing like a word:

private ref struct LockData
{
    private ref ulong _data;   // points at the real lock word, in place
    private ulong _initial;    // what we read
    private ulong _staging;    // what we're building

    public int SharedCounter
    {
        get => (int)(_staging & SharedCounterMask);
        set => _staging = (_staging & ~SharedCounterMask) | (uint)value;
    }

    public ulong State
    {
        get => _staging & StateMask;
        set => _staging = (_staging & ~StateMask) | value;
    }

    // ... SharedWaiters, ExclusiveWaiters, PromoterWaiters, ThreadId

    public bool TryUpdate()
    {
        var succeed = Interlocked.CompareExchange(ref _data, _staging, _initial) == _initial;
        if (!succeed) Fetch();      // someone beat us — re-read and let the caller retry
        return succeed;
    }
}

Now the actual lock logic reads like a state machine, because it is one:

case IdleState:
    if (ld.CanShareStart)
    {
        ld.State = SharedState;
        ld.SharedCounter = 1;
        break;                 // fall through to TryUpdate()
    }
    ...

Two fields assigned, and the whole thing publishes atomically. That's the trick, and it's the part I'd take to any other system: _staging is a local. Every one of those property setters is bit arithmetic on a value sitting in a register — no atomics, no memory barriers, no contention, because nobody else can see it. You mutate it as many times as you like, as legibly as you like, and pay for exactly one atomic operation at the end when TryUpdate publishes the finished word with a single CompareExchange.

A transition that touches four logical fields costs one CAS. Not four. And if it loses the race, Fetch() re-reads the word and the loop reassesses from the new reality — which is why every one of these operations is written as while (true) around a switch. Optimistic, retry-on-collision, no lock to take a lock.

The same file has one more trick worth stealing. Blocking calls take a refWaitContext carrying a deadline and a cancellation token — but most callers want to wait forever and shouldn't pay for the privilege. So they pass ref WaitContext.Null, and the struct checks once:

_isNullRef = Unsafe.IsNullRef(ref ctx);
// ...
public bool ShouldStop => !_isNullRef && _ctx.ShouldStop;

Unsafe.IsNullRef gives you a null reference rather than a nullable value: infinite wait costs one bool test, and the timeout machinery is genuinely absent rather than merely unused.

🪜 The fairness ladder

Now the payoff for those three waiter counters. The entire fairness policy of the lock is three one-line predicates:

public bool CanShareStart        => (_staging & (PromoterWaitersMask | ExclusiveWaitersMask)) == 0;
public bool CanExclusiveStart    => (_staging & PromoterWaitersMask) == 0;
public bool CanPromoteToExclusive => (_initial & SharedCounterMask) == 1;

Read them as a priority ladder — promoters beat writers beat readers:

A new reader may only enter if no writer and no promoter is waiting. This is the anti-starvation rule. Under a heavy read load, a reader-preferring lock lets an endless stream of readers hold the door open forever and a writer waits until the workload changes. (This is the documented default behaviour of ReaderWriterLockSlim.) Here, the instant one writer registers, the reader gate slams: incoming readers queue behind it, the in-flight readers drain, the writer goes.
A new writer stands down for promoters, because a promoter is a thread already holding shared access. Making it wait behind a fresh writer would be perverse — it's already inside.
A promoter may only upgrade when it is the sole reader (counter == 1). Two threads both holding shared access and both trying to upgrade is the textbook promotion deadlock; the counter makes it structurally unrepresentable, because at most one of them can ever see a count of one.

Three masks, one comparison each. No queue, no condition variable, no priority-inheritance logic — a complete fairness policy expressed as "are these bytes zero."

🤏 Four bytes, and what they cost you

Everything above — the waiter counters, the fairness ladder, the explicit state field — is features, and every feature in that word is paid for in bits. So there's a second lock, AccessControlSmall, which spends half as many:

// 15  Shared counter   (bits 0-14, max 32,767)
//  1  Contention flag  (bit 15)
// 16  Thread id        (bits 16-31)

Notice what's missing. There is no state field. State is implied — a non-zero thread id means Exclusive, a non-zero counter means Shared, both zero means Idle. Which has a lovely consequence: the Idle → Exclusive transition, the most common one there is, becomes a single CAS against literal zero.

Also missing: all three waiter counters. And that is the trade, stated plainly — AccessControlSmall has no waiter tracking, therefore no fairness. A pending writer can be starved by a sustained stream of readers. Nothing clever recovers that; you either need the counters or you don't.

So which lock goes where is a straight exchange of features against bytes — and the reason bytes are worth so much more than they look is that some of these locks are not merely in memory. They're in the data.

A latch in a page header lives inside a page that gets written to disk. It is persistent state. Those four-versus-eight bytes are not a transient cost you can buy your way out of with more RAM — they are written on every flush, read back on every load, and they occupy space in the page that would otherwise be holding your data, in every page, for the life of the database. Multiply by a few million pages and the difference stops being an implementation detail and starts being a storage-format decision, which is the kind of decision you don't get to revisit later.

That reframes the whole question. It isn't "smaller is better" — it's that the byte budget of a persistent structure is nothing like the byte budget of a heap object. So the rule is simply: on a structure that's central, in-memory, long-lived and genuinely contended, fairness is worth eight bytes and you take the full lock. On a structure that gets serialized into a page, you take the four-byte one, spend the savings on data, and keep the critical sections short enough that starvation never has the time to develop.

📊 The numbers

Measured with BenchmarkDotNet on an Intel Xeon Platinum 8151 @ 3.40 GHz, Ubuntu 22.04, .NET 10. Each figure is a full acquire and release, single-threaded, with nobody to fight:

Operation	`AccessControl` (8 B)	`AccessControlSmall` (4 B)
Shared: acquire + release	18.8 ns	17.0 ns
Exclusive: acquire + release	21.5 ns	24.5 ns
Promote shared → exclusive → demote	44 ns	45.5 ns

That's the floor, and it is Level 1 of the hierarchy: a CompareExchange on a line already sitting in this core's L1, with no other core wanting it.

Now the opposite extreme — the same shared acquire/release, but with N−1 background threads hammering the same lock word in a tight loop:

Threads contending	Shared: acquire + release
2	940 ns
4	1.86 µs
8	2.00 µs

Fifty to a hundredfold. Nothing about the lock changed between those two tables — same word, same instructions, same code path. The only difference is that the cache line is now being dragged from core to core on every attempt.

I want to be precise about what that second table is, though, because it would be easy to read it as a warning about Typhon and it isn't one. It's a hardware number, not an engine number. It's what a contended CAS costs, obtained by constructing the worst case deliberately: many threads, one word, no work in between. And the engine is built so that scenario doesn't arise.

There is no central lock in Typhon — no handful of monitors that every operation funnels through. There are hundreds of thousands of latches: one per page, per component table, per cluster, per block chain, each held for the tens of nanoseconds it takes to read a header or splice a pointer. For that table to describe the engine, a crowd of threads would have to want the same latch at the same instant. At this granularity, with hold times this short, that is close to a non-event. Not impossible — "almost never" isn't "never" — but it is nowhere near the steady state the benchmark manufactures.

So read that second table as a receipt rather than a warning: it's the bill you'd be handed for centralising your locking, and it's why Typhon doesn't. The answer to contention was never a cleverer lock — it's granularity. Don't make one lock hot; make a hundred thousand cold ones.

⚖️ Trade-offs, and what I got wrong

I nearly went hunting for three nanoseconds that were never there. The 4-byte lock measures slower at exclusive acquisition than the 8-byte one — 24.5 ns against 21.5 — which is the opposite of what its simpler fast path predicts, and I spent a while looking for the flaw in the compact design. There is no flaw. Every field read, every mask, every shift in both locks is register arithmetic, and register arithmetic is free: the entire price of the operation is the Interlocked. And a CAS has no fixed price, only a price in a context — the memory system decides what the line costs, not your bit fields. My bet is that the smaller struct is likelier to share its line with whatever sits beside it, so its CAS pays coherence traffic the other's doesn't. I have no proof and won't pretend otherwise. But a three-nanosecond spread between two locks was never going to be a fact about the locks.

I shrink the lock to 4 bytes and then pad it back to 64. In ArchetypeClusterState the latch is wrapped in a [StructLayout(Size = 64)] struct so it owns an entire cache line — it sits beside hot mutable counters, and false sharing on a lock word is worse than a big lock word. Two threads taking two logically independent locks that happen to share a line will ping-pong it between cores on every CAS, at full contended cost, having never contended for anything; the engine's spatial rules go so far as to forbid bit-packed latch arrays for exactly that reason. So the honest summary of the size story is not "smaller is better." It's: make the lock small enough to live where the data lives, then spend whatever padding it takes to keep its line to itself.

"Zero-cost telemetry" is very nearly true, and I should stop saying "zero." Every acquire and release has a trace-event emit call, gated on a static readonly bool so the JIT can prove the branch dead and delete it. It works — but the off-path benchmark still shows roughly 2 ns per iteration surviving versus an empty method. Two nanoseconds on a 19 ns operation is about 10%, and calling that "free" would be exactly the kind of claim I'd disbelieve in someone else's post.

🎯 The takeaway

The reusable idea isn't the bit layout — yours will be different. It's the staging pattern: read the whole word once, mutate a local copy as many times and as legibly as you want, publish it with one CompareExchange, and retry from the top if you lost.

That structure is what lets you have both of the things people assume are in tension. The lock's state can be arbitrarily rich — five fields, a state machine, a fairness ladder, a diagnostic bit — because manipulating it is just arithmetic on a register that no other thread can see. And it can still be atomic, because "atomic" is a property of the single instruction that publishes the result, not of the reasoning that produced it.

Which leaves exactly one thing that costs anything: the publish. Not the shifts, not the masks, not how many fields you touched on the way — one CompareExchange, and a price set entirely by the state of the cache line it lands on. So the design lever that matters was never what you put in the word. It's where the word lives. Pack it as densely and as cleverly as you like; then go make sure nothing else is touching its line.

Whenever you find yourself reaching for a lock to protect a small piece of state, ask whether the state could be the word instead. Often it fits. And when it fits, the lock stops being an object you acquire and becomes a number you agree on.

⏭️ What's next

This whole post has been about making a latch cost as little as it possibly can. The next one is about the cheaper move — not having the structure at all. Typhon used to carry a primary-key B+Tree, for the very best of reasons: every database has a primary index. That's simply what one does. It turned out to be a reflex imported from a world this engine doesn't live in, because an ECS entity is found by its archetype and its key — it was never going to be walked to through an index. So the whole thing came out. Post #9: Why We Eliminated the Primary Key B+Tree — what it cost to keep, what replaced it, and how to spot the moment you've inherited an assumption instead of making a decision.

Follow the GitHub repo for source and benchmarks, or subscribe via RSS.

The Amazon SQS + SNS connector in redb.Route, at-least-once and pub/sub via SNS SQS. Still leaving MassTransit

rinat kozin — Thu, 16 Jul 2026 13:24:18 +0000

series: "redb.Route"

We've done Kafka and RabbitMQ earlier in this series. Next up: Amazon SQS — and riding along in the same package, SNS. Two transports, because in AWS-land they travel together. The redb.Route.Sqs connector sits on the native AWS SDK for .NET v4 (AWSSDK.SQS, AWSSDK.SimpleNotificationService), but you don't write a "client" — you write routes, and the whole queue collapses into a single URI:

From("sqs://orders?waitTimeSeconds=20&concurrentConsumers=4")
    .Log("Order in: ${body}")
    .To("direct://process");

Read it once and the whole story's there: long-poll the orders queue in 20-second pulls, four consumers wide, log it, pass it on. No "new up a client," no ReceiveMessage, no "remember to DeleteMessage after you've handled it" — the connector does all of that.

About "leaving MassTransit," same disclaimer as last time: it's not that MassTransit can't do this. It's had SQS/SNS for years — MassTransit.AmazonSQS — and it wires up the same SNS→SQS pairing. The difference is the model. MassTransit is a bus — message contracts, consumers, bus config, the whole worldview bought at once. redb.Route is explicit routes in the Apache Camel spirit: an endpoint is a URI, the integration patterns are steps in a route, the transport is an abstraction underneath. This post is about what SQS and SNS look like in that second model.

And the thing everyone's actually asking about right now — worth stating precisely rather than gleefully. MassTransit went commercial with v9: the line now ships under Massient, Inc., and MassTransit.AmazonSQS 9.0.0 on NuGet is already from there. But no spin: v8 stays Apache 2.0, with security patches and critical fixes through at least the end of 2026; v9 isn't a closed binary — it's source-available; and organizations under $1M USD annual revenue (plus non-profits under $1M in expenses) get it at a 100% discount — free, minus commercial support. So "MassTransit is paid now" is false for a small team and true for a large one, where it turns into a real decision: pay, ride v8 to the end of its support, or look around. redb.Route is Apache 2.0, this SQS connector included — but pick it because the routing model fits your head, not because of a license line. A license is a reason to look around; it isn't an argument about architecture.

All the code is in English; the examples aren't invented — they run against LocalStack (a Docker container on http://localhost:4566), the same way the connector's integration tests do.

Part of the redb / redb.Route series — recent posts first:

The RabbitMQ connector — the whole broker in one URI: RPC, competing consumers, dead-lettering (previous in the series)

Leaving MassTransit for a Camel state of mind: the Kafka connector, Scatter-Gather, and transactions

Apache Camel for .NET, dissected: the HTTP connector with no ASP.NET MVC + the Content-Based Router

redb.Route — Apache Camel for .NET: 22 transports, 30+ EIP patterns, compiled DSL

Sources: github.com/redbase-app. About the database itself: redbase.app.

One package, two transports

redb.Route.Sqs registers two schemes, and they don't play the same role:

sqs:// — a queue. Works as both a consumer (in From(...)) and a producer (in .To(...)).
sns:// — a topic. Publisher-only. SNS has no pull consumer — delivery is push (to SQS / HTTP / email / SMS). Try to From("sns://...") and it throws NotSupportedException on purpose: to "read" a topic, you subscribe an SQS queue to it and read that with sqs://.

Why they share a package: at AWS they're a pair. SQS is a durable point-to-point queue (one message, one consumer). SNS is a publish-subscribe topic (one message, every subscriber). The canonical AWS fan-out is an SNS topic with several SQS queues hanging off it — so one connector covers both: sqs:// and sns://.

Wiring it into DI:

services.AddRedbRoute(route =>
{
    route.Services.AddRedbRouteSqs();   // registers both sqs:// and sns://
    route.AddRouteBuilder<MyRoutes>();
});

Anatomy of the URI

An endpoint is a string:

sqs://queue-name?region=us-east-1&waitTimeSeconds=20&concurrentConsumers=4
sns://topic-name?region=us-east-1&autoCreateTopic=true

Scheme, the queue or topic name in the path, then query parameters (names are in the tables below). The fluent builder gives you the same thing: Sqs.Queue("orders").WaitTimeSeconds(20)... and Sns.Topic("events").Region("us-east-1")... build that exact string, URL-encoding included.

Three things are AWS-specific and worth a pause:

Don't repeat your credentials. Twenty queues on one account? Register an AwsConnectionFactory in the registry and point at it with connectionFactory=name. One factory builds both the SQS and the SNS client — they share credentials, region and service URL:

context.AddToRegistry("prod-aws", new AwsConnectionFactory
{
    Region = "eu-west-1",
    UseDefaultCredentialsProvider = true,   // IAM role on the instance / SSO / env vars
});

From("sqs://orders?connectionFactory=prod-aws&concurrentConsumers=4");
To("sns://events?connectionFactory=prod-aws");

LocalStack / ElasticMQ via serviceUrl=. An explicit URL overrides the regional endpoint (the region sticks around only to sign the request). That's your local-dev and test mode:

sqs://orders?serviceUrl=http://localhost:4566&region=us-east-1&accessKey=test&secretKey=test

Queues and topics get created on the spot. autoCreateQueue=true (or autoCreateTopic=true) creates the resource on startup if it's missing. A name ending in .fifo comes up as a FIFO resource automatically, with ContentBasedDeduplication=true.

Every parameter

The reason to bookmark this post. Names are exactly as they appear in the URI; defaults are what you get out of the box.

Connection and credentials (shared by `sqs://` and `sns://`)

Parameter	Default	What it's for
`region`	`us-east-1`	AWS region
`serviceUrl`	(empty)	Explicit endpoint (LocalStack/ElasticMQ); overrides the region
`accessKey` / `secretKey`	(empty)	Static keys
`sessionToken`	(empty)	Temporary (STS) credentials
`profileName`	(empty)	A named profile from the shared credentials file
`useDefaultCredentialsProvider`	`false`	The default AWS chain (env / IAM role / SSO)
`connectionFactory`	(empty)	A factory in the registry; overrides URI credentials
`retryCount`	`3`	SDK retries on transient errors
`connectionTimeout`	`30000`	HTTP client timeout, ms
`proxyHost` / `proxyPort`	—	HTTP proxy

Resolution order: the default chain → a profile → a session token → static keys. Validate() insists on at least one path — accessKey+secretKey, profileName, useDefaultCredentialsProvider=true, or a registered connectionFactory — otherwise it throws at startup.

SQS — consumer (`From("sqs://...")`)

Parameter	Default	What it's for
`waitTimeSeconds`	`20`	Long-poll (0–20). Fewer empty receives, fewer API calls
`maxNumberOfMessages`	`10`	How many to pull per receive (1–10)
`visibilityTimeout`	`0` (queue default)	How long a message stays hidden while you work it
`concurrentConsumers`	`1`	Number of competing receive loops (see the concurrency recipe)
`extendMessageVisibility`	`false`	Keep extending visibility while the handler runs (a heartbeat); needs `visibilityTimeout > 0`
`deleteAfterRead`	`true`	Delete the message after a clean pass (this is the ack)
`resetVisibilityOnFailure`	`false`	On error, reset visibility to 0 → immediate redelivery
`transacted`	`false`	Defer the delete into the route transaction (`.Transacted()`)
`attributeNames`	`All`	Which system attributes to request
`messageAttributeNames`	`All`	Which message attributes to request
`delay`	`0`	Pause (ms) after an empty receive before polling again
`initialDelay`	`0`	Delay (ms) before the first poll

SQS — producer (`.To("sqs://...")`)

Parameter	Default	What it's for
`delaySeconds`	`0`	Delivery delay (0–900). FIFO queues reject a per-message delay
`messageGroupId`	—	FIFO group id. A constant or a `${...}` expression (per message)
`messageDeduplicationId`	—	FIFO dedup id. Skip it if the queue has content-based dedup
`enableBatch`	`false`	Send an `IEnumerable` body as one `SendMessageBatch`
`batchMaxMessages`	`10`	Batch size (SQS's hard cap is 10)
`autoCreateQueue`	`false`	Create the queue on startup (FIFO if the name ends in `.fifo`)
`queueUrl`	(empty)	An explicit queue URL instead of resolving by name

SNS — publisher (`.To("sns://...")`)

Parameter	Default	What it's for
`autoCreateTopic`	`false`	Create the topic on startup (FIFO on `.fifo`)
`topicArn`	(empty)	An explicit topic ARN instead of resolving by name
`subject`	(empty)	Subject (for email delivery). Supports `${...}`
`messageStructure`	(empty)	`json` — per-protocol payloads
`messageGroupId` / `messageDeduplicationId`	—	For FIFO topics
`subscribeSnsToSqs` + `subscribeQueueArn`	`false`	On startup, subscribe an SQS queue (by ARN) to this topic
`rawMessageDelivery`	`false`	On that subscription, deliver the bare payload (see the pub/sub recipe)

Headers and tracing through the broker

The sqs:// consumer stamps message metadata onto the headers (prefixed redbSqs.), and incoming message attributes land under redbSqs.attr.:

Header	What's in it
`redbSqs.queue`	The queue name
`redbSqs.messageId`	Message id
`redbSqs.receiptHandle`	Receipt handle (needed to delete or change visibility)
`redbSqs.approximateReceiveCount`	How many times this message has been delivered ("is this a retry?")
`redbSqs.messageGroupId` / `redbSqs.sequenceNumber`	FIFO group + sequence number
`redbSqs.sentTimestamp`	When it was sent (epoch millis)
`redbSqs.attr.<name>`	An incoming user message attribute

Going the other way, the header → message-attribute mapping on the producer goes like this: user headers ride out as attributes as-is; an incoming redbSqs.attr.<name> is forwarded under the bare <name> (the prefix is stripped, so sqs→sqs and sqs→sns bridges keep their attributes); the internal redbSqs.* / redbSns.* keys are dropped, so one hop's metadata doesn't leak into the next.

Tracing comes for free: before sending, the producer injects the W3C traceparent/tracestate as message attributes via the standard DistributedContextPropagator, and the consumer on the far end picks them up and continues the trace. Over plain SQS (sqs:// → sqs://) the chain is unbroken with zero setup. (There's a wrinkle when SNS is in the middle — see the pub/sub recipe.)

Straight talk on delivery: at-least-once, visibility, transacted

This is where the marketing likes to say "exactly-once." Let's read the code instead.

The SQS consumer is at-least-once. A message is deleted (DeleteMessage) only after it clears the route. The settle logic:

clean pass + deleteAfterRead=true → DeleteMessage (the ack);
failed + resetVisibilityOnFailure=true → ChangeMessageVisibility(0) → it comes right back (fast retry);
failed without that flag → it simply times out on visibility and gets redelivered.

visibilityTimeout is how long the message is hidden while you work it. Long handler? There's extendMessageVisibility=true: a background heartbeat bumps the visibility every visibilityTimeout / 2, so slow work never triggers a redelivery out from under you.

transacted=true rolls the ack into the route transaction. The delete doesn't happen immediately — a deferred SqsAckAction is registered, whose Commit deletes the message and whose Rollback resets visibility to 0 (immediate redelivery). Commit and rollback ride along with your redb work at the .Transacted() boundary:

From("sqs://orders?transacted=true&visibilityTimeout=60")
    .Transacted()
        .ProcessWithRedb((redb, ex) => redb.SaveAsync(Parse(ex)))   // write to the DB
    .EndTransaction();     // DB committed → the message is deleted; DB failed → it comes back

What's not here is cross-queue "read from A, write to B" atomicity at the broker level — SQS doesn't have it to give. Crash in the gap between "work done" and "delete," and after a restart you get a repeat — at-least-once, not exactly-once. So make your handler idempotent; redbSqs.approximateReceiveCount is there to help. The honest label is "at-least-once with a transactional ack at the route level" — no exactly-once fairy dust.

Ordering holds only on a FIFO queue (.fifo) and only with concurrentConsumers=1.

Recipe 1: producer, consumer, FIFO, batch

The bare minimum:

// Consumer — long-poll, delete after success
From(Sqs.Queue("orders").WaitTimeSeconds(20))
    .Process(HandleOrder);

// Producer — send the body to the queue
To(Sqs.Queue("orders").Region("eu-west-1"));

FIFO — the name ends in .fifo, and a group id is required (a constant or a per-message expression):

To(Sqs.Queue("orders.fifo").MessageGroupId("${header.customerId}"));

Batch — an IEnumerable body goes out as a single SendMessageBatch (in chunks of batchMaxMessages, SQS's cap being 10):

From("timer://tick?period=5000")
    .SetBody(_ => new[] { "a", "b", "c", "d", "e" })
    .To(Sqs.Queue("orders").EnableBatch());   // one call instead of five

Recipe 2: competing consumers (concurrency)

One parameter — concurrentConsumers:

From(Sqs.Queue("orders").ConcurrentConsumers(8).MaxNumberOfMessages(1))
    .Process(HandleOrder);   // up to 8 messages handled at once

This is the SQS-native concurrency model: the connector spins up N independent receive loops (one task each), and each pulls and handles its own message. Setting maxNumberOfMessages=1 alongside it makes each of the N workers hold exactly one message at a time, so the pool saturates honestly instead of one loop grabbing a batch of 10. The default is 1 (strictly serial). Go N > 1 and per-queue ordering is off the table, and your handler had better be thread-safe.

How much this actually parallelizes shows up in the SqsRpcDemo (more on it below): 12 requests, roughly 300 ms of work each, a pool of 4 — the whole batch clears in about 1.2 s instead of the ~3.6 s a serial consumer would spend, and the measured peak concurrency pins at exactly 4.

And if what you want to parallelize is the processing inside the route rather than the intake (a serial source, heavy work), there's an orthogonal EIP step, .Threads(N). concurrentConsumers scales reading off the queue; .Threads(N) scales the work; the CONCURRENCY.md guide walks through the difference. They compose freely.

Recipe 3: RPC (request/reply) — and why SQS won't hand it to you

Here's the honest contrast with the last post. On RabbitMQ, RPC flipped on with one flag — replyTo=true on the client and zero config on the server, because the broker does reply queues itself. SQS has none of that — no protocol-level reply-to, no built-in waiting for an answer. RPC over SQS is something you build, using the classic correlation pattern: a reply queue, a correlationId, and matching the answer back. That's exactly what the SqsRpcDemo shows.

The client tags each request with two message attributes — correlationId and replyTo (the queue to answer on) — and drops it on the request queue. The worker computes a result and sends it to the queue named in replyTo; the correlationId rides back on its own (the incoming redbSqs.attr.correlationId is forwarded straight back out as an attribute). The worker is a plain consumer plus a dynamic .ToD(...):

// Worker: N competing consumers on the request queue, reply to the queue named in replyTo
From(Sqs.Queue("rpc-requests").ConcurrentConsumers(4).MaxNumberOfMessages(1))
    .Process(async (ex, ct) =>
    {
        var n = int.Parse(ex.In.Body!.ToString()!);
        await Task.Delay(300, ct);              // simulated work
        ex.In.Body = (n * (long)n).ToString();  // the reply body
    })
    // dynamic destination — the reply queue comes from the request's replyTo attribute
    .ToD(ex => Sqs.Queue(ReplyTo(ex)).Build());

On the client side a separate route reads the reply queue and matches the correlationId back to the pending call:

From(Sqs.Queue("rpc-replies").MaxNumberOfMessages(10))
    .Process((ex, ct) =>
    {
        var id = Attr(ex, "correlationId");
        if (id is not null && Pending.TryRemove(id, out var tcs))
            tcs.TrySetResult(ex.In.Body?.ToString() ?? "");
        return Task.CompletedTask;
    });

The takeaway: RPC on SQS works, but it's assembled from primitives (attributes + .ToD + correlation), not toggled with a flag. When you want RPC out of the box, you reach for a broker with a native reply path (RabbitMQ). SQS is honest about what it is: durable queues and redelivery, and request/reply is a thing you wire up on top. The full, runnable version lives in redb.Route/demos/SqsRpcDemo (it runs against LocalStack).

Recipe 4 (EIP): Publish-Subscribe via SNS→SQS fan-out

Here's the headline pattern, the whole reason SQS keeps SNS company. Publish-Subscribe Channel, straight out of Hohpe & Woolf: the publisher sends one message and every subscriber gets it — independently, into its own queue, with its own retries. At AWS you don't do this in code, you do it with topology: an SNS topic with several SQS queues subscribed to it.

publish "order" ──▶ SNS topic ──┬──▶ SQS "orders-billing"  ──▶ billing route
                                 └──▶ SQS "orders-shipping" ──▶ shipping route

The publisher just publishes to the topic, and every subscribed queue gets a copy — each with its own independent consumer:

// Publisher — publish an order event; SNS fans it out to every subscribed queue:
From("timer://orders?period=5000")
    .SetBody(_ => BuildOrder())
    .To(Sns.Topic("orders-events"));

// Two independent subscribers — each its own SQS queue, each its own consumer:
From(Sqs.Queue("orders-billing")).Process(Charge);
From(Sqs.Queue("orders-shipping")).Process(Ship);

The subscriptions themselves the connector can set up from the URI — subscribeSnsToSqs + the queue ARN; the subscribe runs when the sns:// producer starts. Each sns:// endpoint subscribes one queue (a single ARN), so a two-queue fan-out is two subscriptions on the one topic:

// Subscribe each queue to the topic with raw delivery (bare payload, no envelope):
Sns.Topic("orders-events").SubscribeSnsToSqs(billingArn).RawMessageDelivery();
Sns.Topic("orders-events").SubscribeSnsToSqs(shippingArn).RawMessageDelivery();

For the exact fan-out wiring (creating the queues, reading their ARNs, subscribing, publishing), see redb.Route/demos/SqsPubSubDemo.

⚠️ The catch: the envelope vs. raw

By default SNS does not drop your payload into the queue as-is — it wraps it in a JSON notification envelope:

{ "Type": "Notification", "MessageId": "...", "TopicArn": "...",
  "Message": "<your payload, as a string>", "MessageAttributes": { ... } }

So the subscribing queue receives the envelope, not your message, and your SNS attributes sit inside it rather than as SQS attributes. That's standard AWS SNS behavior (the subscription's Raw Message Delivery = OFF), and it earns its keep in exactly one case: when a single queue listens to several topics and you need the envelope's TopicArn to tell them apart. For an ordinary fan-out it's just in the way — you end up unwrapping the envelope, and the SNS→SQS trace breaks (the traceparent goes inside the envelope, while the SQS consumer looks for it among the SQS attributes).

The fix is the subscription's Raw Message Delivery = true: the queue gets the bare payload, and the SNS attributes become SQS attributes (and the trace is whole again). In the connector that's .RawMessageDelivery() — it sets RawMessageDelivery=true on that subscribeSnsToSqs subscription. The SqsPubSubDemo prints the first delivered body: with .RawMessageDelivery() it's {"orderId":1,"amount":100}, not an envelope.

On rawMessageDelivery. This option lands in the next NuGet release of redb.Route.Sqs. You can already grab it from source right now — the redb.Route.Sqs connector on GitHub (the connector folder — SnsEndpointOptions / SnsProducer / the RawMessageDelivery fluent method). Without it, SNS→SQS still works; you just get the JSON envelope and unwrap it yourself (envelope.Message).

Recipe 5 (a cousin): Multicast — the same fan-out, but inside the route

Publish-Subscribe copies the message on the broker (SNS hands a copy to each subscribed queue). There's a close cousin that copies inside the route — Multicast: your step sends a copy of the exchange to several destinations itself.

From("sqs://orders")
    .Multicast()
        .To("sqs://orders-billing")
        .To("sqs://orders-shipping")
    .End();

Looks similar, but the difference is fundamental — where the copying happens, and who knows about whom:

	SNS→SQS (pub/sub)	Multicast
Where it copies	on the broker (SNS)	in the route (your process)
Who knows the recipients	SNS (the subscriptions)	the route (the `.To` list)
Adding a recipient	subscribe another queue, leave the publisher alone	edit the route's code
Coupling	fully decoupled	recipients are baked into the route
Parallelism / aggregating replies	none (fire-and-forget per subscription)	yes: `.Parallel().MaxParallelism(N)`, merge the branches

The rule of thumb: need to decouple the publisher from the subscribers (anyone can subscribe later, the publisher never knows) — SNS→SQS. Need to fan out to a fixed list right here and maybe collect the answers — Multicast (or its sibling Scatter-Gather from the Kafka post). One is broker topology, the other is a route step; you pick by where the fan-out logic should live.

Wrap-up

SQS and SNS in redb.Route are routes where the whole queue and the whole topic are one URI: From("sqs://…") / .To("sqs://…") / .To("sns://…"), with all the AWS SDK plumbing, the receive/delete dance, visibility, subscriptions and correlation tucked behind the string's parameters. Long-poll, FIFO, batching, competing consumers on a single parameter, at-least-once with a transactional ack, SNS→SQS fan-out with a choice of "envelope or bare payload" — the set is complete, and what you're left with is a short, legible string.

Straight talk on the trade-offs: there's no exactly-once (SQS itself doesn't offer it) — you get at-least-once plus idempotency; RPC isn't out of the box, it's assembled from attributes and .ToD; and an SNS subscription wraps your payload in an envelope by default. All of that is AWS being AWS, not the connector cutting corners — and the connector is upfront about every bit of it.

Two runnable examples — redb.Route/demos/SqsRpcDemo (RPC + concurrency) and redb.Route/demos/SqsPubSubDemo (SNS→SQS fan-out + raw delivery); both come up on LocalStack (http://localhost:4566, test/test) and run as a self-test. If something bites in your scenario, say so in the comments.

Sources and releases: github.com/redbase-app. About the redb database: redbase.app.

If this was useful — a ⭐ on GitHub helps others find it.

Dependency Management Doesn't Have to Be Complicated: A Better Approach for .NET Developers

Marcom — Thu, 16 Jul 2026 11:16:48 +0000

Every .NET developer has encountered dependency issues at some point.

A package version conflict appears after an update. A project suddenly fails to build because of incompatible NuGet packages. Teams spend hours troubleshooting dependency chains instead of writing code.

As applications grow larger and more modular, dependency management becomes increasingly difficult and increasingly important.

The good news is that modern tools are making it easier to identify, analyze, and resolve these issues before they impact development.

NuGet Dependency Mgmt – PalTech USA, UK, Australia

PalTech simplifies NuGet Dependency Management in USA, UK & Australia. Optimize development workflows with consulting & automation services.

pal.tech

Why Dependency Management Matters

NuGet has transformed the .NET ecosystem by making it simple to reuse libraries and accelerate development.

However, every additional package introduces another dependency that must be maintained over time.

Poor dependency management can lead to:

Version conflicts
Build failures
Security vulnerabilities
Difficult upgrades
Increased maintenance effort

For enterprise applications with dozens or even hundreds of dependencies, manually tracking package relationships quickly becomes impractical.

Smarter Dependency Resolution Improves Developer Productivity

Modern dependency analysis tools help developers understand how packages interact across an application.

Instead of manually tracing references, developers can:

Visualize dependency trees
Detect version conflicts early
Identify outdated packages
Simplify upgrade planning
Improve application stability

The result is less time spent debugging package issues and more time focused on delivering business value.

Developer Experience Is Becoming a Competitive Advantage

Organizations often focus on customer experience, but developer experience matters just as much.

When engineers have reliable tooling, automated workflows, and clear visibility into application dependencies, they can develop, test, and deploy software more efficiently.

Small improvements in developer productivity can have a significant impact across large engineering teams.

As software ecosystems continue growing in complexity, better dependency management will become an essential part of modern software engineering.

If you're interested in simplifying package management for .NET applications, PalTech's article, Simplifying NuGet Dependency Management with NuGetSolver, explores how developers can identify dependency conflicts more efficiently, improve project maintainability, and streamline application development.

Modern Secrets for Legacy .NET: Building a Typed, Cached AWS Secrets Manager Library

David Gates — Thu, 16 Jul 2026 10:53:27 +0000

The Problem

If you're building on modern .NET, retrieving a secret from AWS Secrets Manager as a strongly typed, cached configuration value is pretty much turnkey. AWS's supporting NuGet packages handle TTL-based (time-to-live) caching out of the box, and let you bind secrets straight into IConfiguration with only a few lines of code.

If you're maintaining a .NET Framework 4.8 application — and there are more of these in production than any of us would like to admit — none of that tooling exists. The AWS SDK for .NET supports .NET Framework 4.8; you can certainly call AmazonSecretsManagerClient.GetSecretValueAsync from a Framework app today. What doesn't exist is the supporting ecosystem that modern .NET developers take for granted: no typed binding, no caching client, and nothing comparable to IConfiguration's abstraction over configuration sources. You're left hand-rolling JSON deserialization, deciding for yourself whether and how to cache secrets, and wiring the rest together by hand.

A lot of what's still running out there is classic ASP.NET MVC 5 — System.Web.Mvc, Global.asax-based startup, with no built-in dependency injection (DI). That's not a niche scenario; it's the reality for many enterprise applications across organizations of every size.

I ran into this gap firsthand when my organization decided to standardize on AWS Secrets Manager across both modern and legacy .NET applications. The modern apps were straightforward: install the packages, bind to IConfiguration, and you're done. The first .NET Framework 4.8 application was a different story. It needed the same typed retrieval, caching, and clean integration, but none of that infrastructure existed. Every legacy application in our portfolio would face the same challenge. I built DGates.AwsSecretsManager to solve it once, rather than repeating the same solution across every legacy application.

So the goal here wasn't to invent AWS Secrets Manager support for .NET Framework; that already existed. The goal was to close the ergonomics gap: build the kind of typed, cached, DI-friendly wrapper that modern .NET developers get for free today, in a form that a legacy .NET Framework app — including one with no DI container and no modern configuration pipeline — can actually adopt without a rewrite.

The source, NuGet package, and example applications are all available if you'd like to follow along.

Design Decisions & Trade-offs

This is the part of the library that matters — not "I called an AWS SDK method," but the decisions around how to expose it. Every decision came back to one constraint: the library had to feel natural in a .NET Framework 4.8 application, without requiring that application to become more "modern" to use it.

Typed retrieval, not string wrangling. The library's API centers on GetSecretAsync<T> — deliberately mirroring the typed configuration binding modern .NET developers already expect. Tell it what shape you expect back, and it hands you an object — not a JSON blob you deserialize yourself three call sites later. GetSecretStringAsync exists too, for the cases where a secret genuinely is just a string and wrapping it in a POCO (plain old CLR object) would be overkill. RefreshSecretAsync<T> and InvalidateCache round out the API — force a refresh when you know a secret rotated, or drop it from cache entirely without waiting for TTL expiry.

Caching: ConcurrentDictionary, not IMemoryCache. This one is a deliberate departure from what a lot of people would reach for first. Microsoft.Extensions.Caching.Memory is the obvious modern choice, but pulling it into a .NET Framework 4.8 library means dragging in a dependency chain built for a different runtime generation, plus the DI registration ceremony that comes with it. That's exactly the kind of friction we want to avoid with this library. A ConcurrentDictionary keyed by secret name, storing the value alongside its expiry, does everything needed here: thread-safe reads and writes, no extra package, no DI requirement. CacheTtl is exposed as a TimeSpan rather than an int, because "how long should this live" is a duration, and forcing a caller to remember whether an int means seconds or milliseconds is the kind of API ambiguity that causes production incidents at 2 a.m.

Resilience: Polly, scoped narrowly. Secrets Manager calls can fail transiently, and retrying blindly can be worse than not retrying at all if you're not careful about what you retry. Polly 8 wraps the AWS calls specifically for transient failure modes — throttling, temporary network failures, and similar conditions — not as a blanket "wrap everything and hope" policy. Non-transient failures, like invalid credentials or a secret that does not exist, surface immediately instead of being retried into a longer, more confusing failure.

DI-agnostic by design. This decision came directly from the target audience. A modern ASP.NET app has a DI container built in. A classic ASP.NET MVC 5 app, running through Global.asax, does not. Forcing a specific container (Autofac, Unity, whatever) onto a legacy app just to use this library would be limiting and defeat the purpose. Instead, SecretsManagerServiceFactory builds a configured SecretsManagerService directly, and SecretsManagerService itself is directly instantiable — no container required. Consumers who do have a DI container can register it as usual; consumers who don't can call the factory once at startup and hold the result in a static accessor. Both are first-class, not one blessed path and one workaround.

The same restraint applies to authentication. SecretsManagerSettings accepts an explicit AccessKey and SecretKey for the cases that genuinely need them, but when those values are omitted, the library defers to the AWS SDK's standard credential chain — environment variables, an .aws/credentials profile, or an IAM role. Rather than inventing its own authentication model, the library relies on the one AWS developers already know and expect.

Local development without AWS. None of the above matters much if testing it locally means burning AWS API calls against a real Secrets Manager instance every time you hit F5, or requiring an AWS account just to try the library out. The library ships with a docker-compose.yml that spins up LocalStack and a seed script that populates it with test secrets, so a fresh checkout can run the integration tests against a fully local AWS emulation with a single command: no AWS account, no manual setup. The examples repo follows the same pattern.

For environments where Docker isn't available — nested VMs without virtualization passthrough are a common setup in practice — there's a LocalJsonFallbackPath that reads secrets from a local JSON file instead. It's not a mock; it's a genuine fallback path, wired the same way the real client is, so switching between "talk to LocalStack," "talk to real AWS," and "read a local file" is a configuration change, not a code change. (To be clear: this fallback is a local development and testing convenience, not something intended for production use.)

Proving It in a Real App: MvcExample

Could every application implement this itself? Absolutely — the AWS SDK makes that possible, if not particularly pleasant. But once you're standardizing Secrets Manager across dozens of legacy applications, the problem isn't writing another JSON deserializer. It's making sure every application gets the same caching behavior, retry policy, configuration model, and local development experience — instead of a dozen slightly different, independently maintained versions of the same idea.

A library intended for ASP.NET MVC 5 isn't really proven by a console sample alone. To validate DGates.AwsSecretsManager in the kind of environment it was actually built for, I created a classic ASP.NET MVC 5 application — MvcExample — where a user enters a city, the app retrieves an OpenWeatherMap API key from Secrets Manager, geocodes the city, and fetches live weather. A "how this worked" panel shows the secret name, the retrieved URL, and which backend served the request — real AWS, LocalStack, or the JSON fallback.

Startup integration is a single factory call — no DI container required:

// Global.asax.cs — Application_Start
var secrets = SecretsManagerServiceFactory.Create(new SecretsManagerSettings
{
    Region = "us-west-2",
    CacheTtl = TimeSpan.FromMinutes(15),
    LocalJsonFallbackPath = Server.MapPath("~/App_Data/secrets.local.json")
});

Retrieval is one typed call — the secret comes back as a POCO, already deserialized, already cached:

var secret = await secrets.GetSecretAsync<OpenWeatherMapSecret>("dev/MvcExample/OpenWeatherMap");

That's the ergonomics gap from the start of this post, closed: typed, cached, and wired into a Global.asax-era app without a rewrite.

In MvcExample, both calls live behind a small static accessor class: it reads the settings from Web.config instead of hardcoding them, guards initialization so the service is built exactly once, and wraps retrieval results with the metadata the "how this worked" panel displays. None of that is required by the library itself — it's the app's own glue — but the pattern is worth copying if you want environment-specific configuration without a recompile. See SecretsManagerAccessor.cs for the full version.

Legacy packaging friction. MVC5 projects use packages.config, and DGates.AwsSecretsManager brings the AWS SDK's sizeable transitive dependency tree with it — something you do not want to manage through hand-wired HintPath entries. The long-term solution is to convert the legacy project's packages to PackageReference and isolate all library-facing code in a small SDK-style project — in this case, MvcExample.Infrastructure. The web project references that project through ProjectReference, letting MSBuild resolve the full dependency graph while the legacy project never has to know the AWS SDK exists. As a bonus, the conversion also enables dotnet restore, making clean command-line and CI builds possible without relying on Visual Studio.

Two operational lessons. First, Application_Start runs eagerly — so an unreachable Secrets Manager at startup meant a crashed app pool, not an error page. Initialization is now handled defensively, surfacing failures as an in-page message at first real use instead. Second, LocalJsonFallbackPath isn't automatic — if you want the fallback, it has to be wired explicitly at the consumer's configuration call site. It was missing entirely from MvcExample's initial setup, a reminder that it needs to be verified in every new consumer, not assumed from the README.

What the panel doesn't show. The "how this worked" panel doesn't display a cache-hit indicator, and that's deliberate. Building one would have meant inferring the library's internal cache state from the outside rather than reporting something real — false precision dressed up as telemetry. Better to show nothing than something that looks like data but isn't.

Building & Publishing

A .NET Framework 4.8 library in 2026 raises an immediate CI question: what does the pipeline even run on? GitHub Actions' Windows runners are the obvious answer, but LocalStack ships as a Linux container and isn't supported under Windows containers. The library is built and tested on ubuntu-latest instead, using Mono to run the .NET Framework test suite. Linux runners also spin up faster, and keeping the pipeline on one OS keeps it simple — the same environment builds the library, runs the tests against LocalStack, and packs the NuGet package.

There's one hard limit to know about: this works for building .NET Framework code, not running classic ASP.NET on Linux. Compiling the MVC 5 example app on ubuntu-latest works fine; hosting it does not — Mono's xsp4 web host is broken and unmaintained. Build on Linux, run on Windows via IIS Express. That boundary is worth knowing before you design a pipeline around either assumption.

Two principles shaped the rest of the pipeline:

No NuGet API keys, anywhere. Publishing uses NuGet's Trusted Publishing — the workflow authenticates via OIDC (OpenID Connect), meaning NuGet.org trusts a short-lived token issued by GitHub Actions for this specific repository and workflow, rather than a long-lived API key stored as a repository secret. There is nothing to leak, rotate, or accidentally commit. For a library whose entire purpose is keeping secrets out of the wrong places, publishing it with a static credential would have been a little too ironic.

Integration tests run against real (local) infrastructure. The same docker-compose.yml and seed script that power local development spin up LocalStack in CI, so the integration tests exercise genuine Secrets Manager API behavior on every push — not mocks. The local-dev investment from earlier paid for itself here: CI didn't need its own separate test infrastructure, because the local story already was one.

Lessons Learned

Three things stand out looking back at this project — none of them about AWS or Secrets Manager specifically.

Local development isn't an afterthought. The LocalStack setup and the JSON fallback path took real time to build — time that could have gone toward features. It was worth it twice over. During development, the zero-dependency local story meant every design decision could be exercised immediately, in environments ranging from a full Docker setup to a locked-down VM with nothing on it. Then it paid off again in CI: the same docker-compose.yml and seed script that power local development became the integration test infrastructure, with no separate CI-only setup to build or maintain. Investment in the development experience compounds; it isn't overhead.

Design for the audience you actually have. It would have been easier to build this with the newest patterns available: a modern DI container, IOptions-style configuration, the latest caching abstractions. The applications that need this library can't use any of that. Every design decision in this post traces back to accepting that constraint instead of fighting it: the DI-agnostic factory exists because the target apps have no container, converting package management is a much smaller step than rewriting the project around an SDK-style project model, and configuration flows through Web.config because that's where these apps keep it. Meeting legacy applications where they are is what makes incremental modernization possible at all.

Consistency scales; convenience doesn't. Any individual application could hand-roll its own Secrets Manager integration in an afternoon. Taken once, that's perfectly reasonable. Taken a dozen times across a portfolio, it produces a dozen slightly different caching policies, retry behaviors, and configuration conventions, each independently maintained, each evolving in slightly different directions. A shared library means one implementation to test, one set of behaviors to reason about, and one place to fix a bug that would otherwise be a dozen tickets. The value isn't that it saved anyone from writing a JSON deserializer — it's that nobody has to wonder which version of the pattern any given app is running.

Final Thoughts

The surprising part of this project wasn't the implementation itself. It was realizing that the hardest problems weren't making it work — they were making it fit. Legacy applications aren't difficult because they're old; they're difficult because they're valuable enough to keep running while the world around them changes.

That's ultimately what DGates.AwsSecretsManager aims to provide: not new capabilities, but modern ergonomics for software that's still doing real work.

If this library helps even a handful of teams modernize legacy applications incrementally instead of rewriting them all at once, it will have done exactly what it was built to do.

What's Next

The library is currently in beta. Before a stable 1.0 release, I want to focus on two areas: structured logging and deeper documentation of the design decisions covered here. Beyond that are ideas like cache stampede protection, serializer abstraction, and rotation handling — but roadmaps change, so the issue tracker remains the source of truth for what's actually planned.

If you're maintaining .NET Framework applications and this problem looks familiar, I'd love to hear how you're solving it — or whether DGates.AwsSecretsManager helps. Feedback from real legacy codebases is worth more than any roadmap.

Building a Zero-Hardware Keyboard Light: My Journey with C#, WPF, and OLED Efficiency

Mihai Pavelescu — Thu, 16 Jul 2026 09:27:10 +0000

Working late nights on server migrations and code architectures often means typing in low-light environments. While USB lamps or backlit keyboards are the standard solutions, they consume extra power and add physical clutter. I realized the ultimate light source was already directly in front of me: the monitor.

With a clear vision in mind, I partnered with Google's Gemini AI to rapidly prototype and refine what became LightBar For Keyboard, a lightweight Windows application that creates a reflective light bar at the bottom of the screen to illuminate the keys. Here is how we built it using C# and WPF, tackled the Windows API to manage screen space, and optimized it for modern OLED energy consumption.

The Core Challenge: Desktop Toolbars (AppBar)

The simplest approach to creating a light bar is a borderless, top-most window. However, the immediate UX flaw is that maximized applications (like Chrome or Visual Studio) will either cover the bar or be partially obscured by it.

To solve this, the application needed to behave like the Windows Taskbar. I implemented the native Windows Application Desktop Toolbar (AppBar) API using SHAppBarMessage from shell32.dll.

Docked Mode: By registering the application as an AppBar and setting the edge to ABE_BOTTOM, Windows automatically recalculates the working area of the desktop.
Result: Maximized windows are pushed upward, ensuring the light bar remains entirely visible and never covers any underlying application UI.
Floating Mode: For users who need temporary access to the bottom of their screen, I added a state toggle that unregisters the AppBar and enables standard drag-and-drop window movement via MouseLeftButtonDown.

Enforcing a Single Instance

Because the app directly manipulates the desktop working area, launching multiple overlapping instances would cause UI glitches. To prevent this, I implemented a Mutex in App.xaml.cs to guarantee a single instance constraint.

protected override void OnStartup(StartupEventArgs e)
{
    const string appName = "LightBarForKeyboard_UniqueInstance";
    bool createdNew;

    _mutex = new Mutex(true, appName, out createdNew);

    if (!createdNew)
    {
        Environment.Exit(0);
    }

    base.OnStartup(e);
    // ...
}

The OLED Efficiency Pivot

Initially, the application featured a pure white bar. On standard LCD panels (IPS, TN, VA), the monitor's backlight is entirely on anyway. Displaying a white bar at the bottom of the screen simply twists the liquid crystals to let the existing light pass through. The extra power required is literally 0 W.

However, OLED displays generate light per pixel. A full white bar firing all RGB subpixels across the bottom of a wide monitor consumes approximately 2,0 W. To make the software highly efficient on modern displays, we introduced custom color profiles targeting specific subpixels:

Pure Green (RGB 0, 255, 0): The human eye is highly sensitive to green light. This provides maximum contrast for reading black keyboard keys while bypassing the blue and red subpixels entirely. Consumption: ~0,5 W (75% savings).
Pure Red (RGB 255, 0, 0): Excellent for protecting night vision, allowing the user to look away from the screen without eye strain. Consumption: ~0,3 W (85% savings).
Yellow (RGB 255, 191, 0): A warm, eye-friendly glow achieved by mixing red and green, completely keeping the power-hungry blue subpixel turned off. Consumption: ~0,8 W (60% savings).

Users can seamlessly right-click the bar to switch between these profiles depending on their hardware and lighting preferences.

Deployment and SmartScreen Realities

I packaged the project as a self-contained, single-file executable using .NET 10.0:

dotnet publish -c Release -r win-x64 --self-contained true -p:PublishSingleFile=true -p:IncludeNativeLibrariesForSelfExtract=true

For distribution, I generated an Inno Setup installer. As an independent developer releasing free tools, purchasing an expensive EV Code Signing certificate isn't always practical. Consequently, early adopters will encounter the classic Windows Defender SmartScreen "Windows protected your PC" blue prompt. I added a quick disclaimer in the documentation to guide users to click More info > Run anyway, knowing that as the software gains organic downloads, its Microsoft SmartScreen reputation will naturally build.

Wrapping Up

Building this utility—and co-piloting the development process with Gemini—was a highly satisfying exercise in merging legacy Windows APIs with modern hardware considerations. It is a completely free, software-only solution to a hardware problem.

If you want to try it out, check the code, or compile it yourself, the entire project is open-source on GitHub: LightBarForKeyboard Repository.

Fuse v4.3, an open source MCP/CLI tool to speed up Claude Code on C# codebases

A. Shafie — Thu, 16 Jul 2026 07:59:26 +0000

Fuse 4.2 is an open source .NET global tool that runs as an MCP server or from the command line.

I built Fuse after watching coding agents repeatedly read and search the same .NET files. Across several turns, they would reconstruct symbols, references, dependency injection registrations, and project structure they had already encountered.

On the write side, proposed C# changes often went through a longer edit and dotnet build loop just to find an invalid member, missing argument, or incompatible type.

Fuse addresses these two parts of the workflow: code discovery and earlier compiler feedback.

Reusing .NET discovery

Fuse loads the solution through MSBuild, analyzes C# with Roslyn, and stores the derived index locally in .fuse/fuse.db. Changed files are updated incrementally, so later requests can reuse the existing index.

The index supplies exact symbol lookup, .NET framework wiring, reduced task-scoped source, change impact, and Git-seeded branch review.

For example, text search can find every occurrence of IOrderService. Fuse can follow the dependency injection registration to the implementation used by the application. It can also resolve a MediatR request to its handler, an ASP.NET route to its action, or a configuration section to its options class.

When Claude Code needs source, Fuse selects files from indexed anchors and reduces their content under a token budget. The response includes the reason each file was selected, and later calls in the same session can skip unchanged context already returned.

Checking proposed C# edits

fuse_check accepts the proposed content of one C# file without changing the working tree.

When compiler state captured from the real build is available, Fuse checks the proposal against that compilation. Otherwise, it falls back to a scoped build for the project that owns the file. If neither compiler path can run, Fuse abstains and reports what is missing.

This check does not replace the final build or test run. It gives the coding agent compiler feedback earlier, before committing a proposed file to disk and starting the normal verification loop.

Fuse also provides change-impact queries, covering-test selection, compiler-executed refactoring, and review context based on the current Git diff. These operations use the same local index.

Scope and related tools

Repository indexes and code graphs already exist. CodeGraphContext provides a local multi-language graph, Serena exposes language-server-backed symbol operations, Sourcegraph covers code search across repositories, and coding clients maintain their own indexes.

The C# LSP also handles definitions, references, type information, live diagnostics, and editor refactoring. Fuse can run alongside it.

Fuse has a narrower scope: local .NET analysis through MSBuild and Roslyn, including framework-specific wiring, reduced source for the current task, and checks against compiler state captured from the repository's real build.

Recorded results

On the recorded NodaTime semantic index with 14,760 symbols, exact symbol lookup took 1.8 ms at the median. Task localization took 15.7 ms at the median.

In a separate compiler-labeled suite over the OrderingApp test families, Fuse recorded 0 false green and 0 false red across 1,000 generated single-file edits plus 8 curated cases.

Both results are bounded to the recorded machines, repositories, and test samples. The benchmark pages include the weaker results as well, including cases where open-ended localization has limited signal and the agent loop did not reduce the number of normal build and test calls.

Install

Install Fuse as a .NET global tool and connect it to Claude Code:

dotnet tool install -g Fuse
fuse mcp install --client claude --rules

Reload Claude Code after installation. MCP read tools build the index on first use, or you can build it explicitly:

fuse index

Analysis runs locally and can work offline. Fuse does not require a hosted service or its own model. The optional update check and builds using configured package feeds are the network-dependent cases.

Repository: github.com/Litenova-Solutions/Fuse
Documentation: fuse.codes
Methods and limits: fuse.codes/docs/project/benchmarks
Reproduction: fuse.codes/docs/project/reproduce

ASP.NET Core mesCode

mesCode — Thu, 16 Jul 2026 06:03:18 +0000

In this backend development guide, we are setting up a secure RESTful API endpoint using ASP.NET Core Web API.

1. Database Configuration (appsettings.json)

First, configure your SQL Server connection details inside the application environment variables. You can either use Windows Integrated Security or standard SQL Server Authentication.

Option A: Integrated Security (Windows Auth)

"AllowedHosts": "*", "ConnectionStrings": { "DefaultConnection": "Server=nameofserver;Database=nameofDB;Integrated Security=True;MultipleActiveResultSets=True;TrustServerCertificate=True;" } }

Option B: SQL Server Authentication

"AllowedHosts": "*", "ConnectionStrings": { "DefaultConnection": "Server=nameofserver;Database=nameofDB;User Id=your_username;Password=your_password;MultipleActiveResultSets=True;TrustServerCertificate=True;" } }

Defining the Service Contract (IService.cs) To maintain loose coupling, we define an asynchronous interface containing standard CRUD contracts for our data mutations.

Task<IEnumerable<Student>> GetAllStudentsAsync(); Task<Student> GetStudentByIDAsync(int id); Task<int> AddStudentAsync(Student student); Task<int> UpdateStudentAsync(Student student); Task<int> DeleteStudentAsync(int id);

Core Architecture: Async Stored Procedure Execution (StudentService.cs) Here is the underlying service layer that handles optimal stream reading with native asynchronous ADO.NET extensions.

` public class StudentService(IConfiguration config) : IStudentService
{
private string connectionString = config.GetConnectionString("DefaultConnection")!;

 public async Task<IEnumerable<Student>> GetAllStudentsAsync()
 {
     try
     {
         var students = new List<Student>();
         using var connection = new SqlConnection(connectionString);
         using var command = new SqlCommand("[GetAllStudent]", connection)
         {
             CommandType = System.Data.CommandType.StoredProcedure,
         };
         await connection.OpenAsync();
         using var reader = await command.ExecuteReaderAsync();
         while (reader.Read())
         {
             Student student = new Student();
             {
                 student.StudentID = reader.GetInt32(reader.GetOrdinal("StudentID"));
                 student.StudentName = reader.GetString(reader.GetOrdinal("StudentName"));
                 student.Email = reader.GetString(reader.GetOrdinal("Email"));
                 student.Phone = reader.GetString(reader.GetOrdinal("Phone"));
                 student.Gender = reader.GetString(reader.GetOrdinal("Gender"));
                 student.Address = reader.GetString(reader.GetOrdinal("Address"));
                 student.Rank = reader.GetDecimal(reader.GetOrdinal("Rank"));
                 student.DOB = reader.GetDateTime(reader.GetOrdinal("DOB"));
                 student.CourseID = reader.GetInt32(reader.GetOrdinal("CourseID"));
                 student.CourseName = reader.GetString(reader.GetOrdinal("CourseName"));

             }
             ;
             students.Add(student);
         }
         return students;
     }
     catch (Exception ex)
     { 
         throw new Exception($"error retrirving Student: {ex.Message}", ex);
     }

 }
 public async Task<Student> GetStudentByIDAsync(int id)
 {
     try
     {

         using var connection = new SqlConnection(connectionString);
         using var command = new SqlCommand("[GetstudentbyID]", connection)
         {
             CommandType = System.Data.CommandType.StoredProcedure
         };
         command.Parameters.AddWithValue("@StudentID", id);
         await connection.OpenAsync();
         using var reader = await command.ExecuteReaderAsync();
         Student std = new Student();
         while (await reader.ReadAsync())
         {
             Student student = new Student();
             {
                 student.StudentID = reader.GetInt32(reader.GetOrdinal("StudentID"));
                 student.StudentName = reader.GetString(reader.GetOrdinal("StudentName"));
                 student.Email = reader.GetString(reader.GetOrdinal("Email"));
                 student.Phone = reader.GetString(reader.GetOrdinal("Phone"));
                 student.Gender = reader.GetString(reader.GetOrdinal("Gender"));
                 student.Address = reader.GetString(reader.GetOrdinal("Address"));
                 student.Rank = reader.GetDecimal(reader.GetOrdinal("Rank"));
                 student.DOB = reader.GetDateTime(reader.GetOrdinal("DOB"));
                 student.CourseID = reader.GetInt32(reader.GetOrdinal("CourseID"));
                 student.CourseName = reader.GetString(reader.GetOrdinal("CourseName"));
             }
             ;
             std = student;
         }
         return std;
     }
     catch (Exception ex)
     {
         throw new Exception($"Error Get student: {ex.Message}", ex);
     }
 }

 public async Task<int> AddStudentAsync(Student student)
 {
     try
     {
         using var connection = new SqlConnection(connectionString);
         using var command = new SqlCommand("[SaveStudent]", connection)
         {
             CommandType = System.Data.CommandType.StoredProcedure
         };

         command.Parameters.AddWithValue("@StudentID", student.StudentID);
         command.Parameters.AddWithValue("@StudentName", student.StudentName);
         command.Parameters.AddWithValue("@Email", student.Email);
         command.Parameters.AddWithValue("@Phone", student.Phone);
         command.Parameters.AddWithValue("@Gender", student.Gender);
         command.Parameters.AddWithValue("@Address", student.Address);
         command.Parameters.AddWithValue("@Rank", student.Rank);
         command.Parameters.AddWithValue("@DOB", student.DOB);
         command.Parameters.AddWithValue("@CourseID", student.CourseID);
         await connection.OpenAsync();
         var result = await command.ExecuteNonQueryAsync();
         return result;

     }
     catch (Exception ex)
     {
         throw new Exception($"Erro Add Student: {ex.Message}", ex);
     }

 }`

RESTful API Presentation Layer (Controller.cs) Expose the endpoints using attributes routing so that front-end modern frameworks can interact safely via HTTP request methods.

` public class StudentController(IStudentService _studentService) : ControllerBase
{
[HttpGet("student")]
public async Task GetAllStudents()
{
try
{
var students = await _studentService.GetAllStudentsAsync();
return Ok(students);

     }
     catch (Exception ex)
     {
         return BadRequest(ex.Message);
     }

 }

 [HttpGet("{id:int}")]
 public async Task<IActionResult> GetStudentbyID(int id)
 {
     var student = await _studentService.GetStudentByIDAsync(id);
     if (student == null)
     {
         return NotFound($"Student With Id {id} not found");
     }
     return Ok(student);
 }

 [HttpPost]
 public async Task<IActionResult> AddStudent([FromBody] Student student)
 {
     var result = await _studentService.AddStudentAsync(student);
     return Ok(result);

 }
 [HttpPut("{id}")]
 public async Task<IActionResult> UpdateStudent(int id, [FromBody] Student student)
 {
     var result = await _studentService.UpdateStudentAsync(student);
     return NoContent();
 }

 [HttpDelete("{id:int}")]

 public async Task <IActionResult> DeleteStudent(int id)
 {
     var result = await _studentService.DeleteStudentAsync(id);
     return NoContent();
 }`

Dependency Injection & Service Registration (Program.cs) Register the custom domain services and open global Cross-Origin Resource Sharing (CORS) rules to enable decoupling integrations.

// Learn more about configuring Swagger/OpenAPI at https://aka.ms/aspnetcore/swashbuckle builder.Services.AddEndpointsApiExplorer(); builder.Services.AddSwaggerGen(); _builder.Services.AddScoped<IStudentService,StudentService>();_

`// Configure the HTTP request pipeline.
if (app.Environment.IsDevelopment())
{
app.UseSwagger();
app.UseSwaggerUI();
}

app.UseCors(builder =>
builder.AllowAnyOrigin()
.AllowAnyMethod()
.AllowAnyHeader());
`

.NET 8 and .NET 9 Both Die on November 10 - Yes, the LTS Too

endoflife-ai — Thu, 16 Jul 2026 02:21:19 +0000

Originally published at endoflife.ai.

Here's a date collision that surprises people: .NET 8 and .NET 9 reach end of support on the same day — November 10, 2026.

The instinctive reaction is "but 8 is the LTS!" — and that's exactly the trap. LTS doesn't mean long, it means longer. The math:

.NET 8 (LTS): released November 2023, supported 3 years → dies November 10, 2026
.NET 9 (STS): released November 2024, supported 2 years → dies November 10, 2026

Different tracks, same cliff. Anyone who "played it safe" on the LTS and anyone who rode the STS end up in the identical position this November.

What end of support actually means

After November 10, Microsoft ships no security patches for either runtime — including for vulnerabilities that get actively exploited later. Your app keeps running; it just stops getting defended. CVEs published against the runtime after that date are permanent for you.

For teams with compliance obligations, "unsupported runtime in production" is an audit finding, not a philosophical debate.

The only forward path is .NET 10

.NET 10 (LTS) shipped November 11, 2025 and is supported to November 14, 2028. For most 8→10 moves the upgrade is mercifully boring — retarget, run the test suite, chase a handful of breaking changes. The teams that get hurt are the ones who discover a transitive dependency pinned to an EOL runtime in December, not the ones who retargeted in September.

Worth separating in your head: .NET Framework 4.8 (the old Windows-only one) is a different animal — it has no fixed end date and lives as long as the Windows version hosting it. Modern .NET (Core lineage) is the one on the November clock. If you're still on Framework, your deadline is your Windows Server's deadline instead.

Put a date on it

The November 10 cutoff sits inside a brutal H2 2026 calendar: SharePoint 2016/2019 and SQL Server 2016 already died July 14, OpenSSL 3.0 goes September 7, Python 3.10 on October 31, PostgreSQL 14 on November 12, PHP 8.2 on December 31.

Every date above is verified against vendor lifecycle sources. Full deadline coverage lives at endoflife.ai/eol-watch, you can check any product's status in seconds with the EOL checker, or scan a whole project file with the stack scanner. There's also a free API if you'd rather gate this in CI:

curl https://api.endoflife.ai/v1/status/dotnet/8
# "is_eol": false ... until November 10.

DEV Community: dotnet

StructoFox: Flowcharts->structograms->code

Asdamir: Scaffold a working .NET 10 + Blazor enterprise app in 2 commands

What it does

Adding a feature is one command

Full quick-start

Free mode is genuinely standalone

Why I built it

I'd love feedback

Design Patterns in C# Part 2: Structural Patterns - Adapter, Decorator, Facade, and Composite

Pattern 1: Adapter

Pattern 2: Decorator

Pattern 3: Facade

Pattern 4: Composite

Key Lessons

What's Next

Summary

v0.2.0 - Horus.F5Tts.Onnx - MASSIVE improvements

The 8-Byte Lock: Packing a Reader-Writer Lock Into 64 Bits

📍 Where we are

🔒 Why not just use the lock in the box?

🧩 What fits in sixty-four bits

🧵 Why the thread id is exactly sixteen bits

💎 The prettiest code in the engine

🪜 The fairness ladder

🤏 Four bytes, and what they cost you

📊 The numbers

⚖️ Trade-offs, and what I got wrong

🎯 The takeaway

⏭️ What's next

The Amazon SQS + SNS connector in redb.Route, at-least-once and pub/sub via SNS SQS. Still leaving MassTransit

One package, two transports

Anatomy of the URI

Every parameter

Connection and credentials (shared by sqs:// and sns://)

SQS — consumer (From("sqs://..."))

SQS — producer (.To("sqs://..."))

SNS — publisher (.To("sns://..."))

Headers and tracing through the broker

Straight talk on delivery: at-least-once, visibility, transacted

Recipe 1: producer, consumer, FIFO, batch

Recipe 2: competing consumers (concurrency)

Recipe 3: RPC (request/reply) — and why SQS won't hand it to you

Recipe 4 (EIP): Publish-Subscribe via SNS→SQS fan-out

⚠️ The catch: the envelope vs. raw

Recipe 5 (a cousin): Multicast — the same fan-out, but inside the route

Wrap-up

Dependency Management Doesn't Have to Be Complicated: A Better Approach for .NET Developers

NuGet Dependency Mgmt – PalTech USA, UK, Australia

Modern Secrets for Legacy .NET: Building a Typed, Cached AWS Secrets Manager Library

The Problem

Design Decisions & Trade-offs

Proving It in a Real App: MvcExample

Building & Publishing

Lessons Learned

Final Thoughts

What's Next

Building a Zero-Hardware Keyboard Light: My Journey with C#, WPF, and OLED Efficiency

The Core Challenge: Desktop Toolbars (AppBar)

Enforcing a Single Instance

The OLED Efficiency Pivot

Deployment and SmartScreen Realities

Wrapping Up

Fuse v4.3, an open source MCP/CLI tool to speed up Claude Code on C# codebases

Reusing .NET discovery

Checking proposed C# edits

Scope and related tools

Recorded results

Install

ASP.NET Core mesCode

1. Database Configuration (appsettings.json)

Option A: Integrated Security (Windows Auth)

Option B: SQL Server Authentication

.NET 8 and .NET 9 Both Die on November 10 - Yes, the LTS Too

What end of support actually means

The only forward path is .NET 10

Put a date on it

Connection and credentials (shared by `sqs://` and `sns://`)

SQS — consumer (`From("sqs://...")`)

SQS — producer (`.To("sqs://...")`)

SNS — publisher (`.To("sns://...")`)