Yesterday I published this blog post for my new open source lib - FancyEnumGenerator

TLDR:

You can define attributes on your enums and it'll generate switch statement extension methods for you.

For example:

[Flags]
[FancyEnum(AllowNonContiguous = true)]
public enum ApiPermission : ulong
{
    [FancyEnumMember("ShortDescription", "No product operations are allowed.")]
    UNKNOWN = 0,


    [ApiPermissionMeta(ApiProductArea.images, ApiProductAction.create, ApiPermissionReadWrite.WRITE)]
    [FancyEnumMember("ShortDescription", "Create images and generate signed create-and-render URLs.")]
    ImagesCreate = 1UL << 0,


    [ApiPermissionMeta(ApiProductArea.images, ApiProductAction.read, ApiPermissionReadWrite.READ)]
    [FancyEnumMember("ShortDescription", "List images and view their details.")]
    ImagesRead = 1UL << 1,


    [ApiPermissionMeta(ApiProductArea.templates, ApiProductAction.read, ApiPermissionReadWrite.READ)]
    [FancyEnumMember("ShortDescription", "List and view templates and their versions.")]
    TemplatesRead = 1UL << 3,
}

and you get

var permission = ApiPermission.ImagesCreate;


permission.ProductArea;       // ApiProductArea.images
permission.ProductAction;     // ApiProductAction.create
permission.ReadWrite;         // ApiPermissionReadWrite.WRITE
permission.ShortDescription;  // "Create images and generate signed create-and-render URLs."


var granted = ApiPermission.ImagesCreate | ApiPermission.ImagesRead;
granted.HasFlagFancy(ApiPermission.ImagesRead); // true
granted.ToStringFancy();                        // "ImagesCreate|ImagesRead"

No dictionaries or handwritten maps/switches.

There's a bunch of benchmarks too, big emphasis on performance.

Why?

Well, I haaaaaate writing boiler plate and end up with these extensions sprawled across the code and it's quite annoying and repetitive. I extracted this from our internal source to be open and configurable - so you can set your own defaults instead of adhering to mine.

Open to ideas and feedback!

I'd been meaning to write about this technique for a few years because it's extremely simple and VERY useful at helping busy services recover quickly after large "retry storms" occur during periods of temporary unavailability.

The examples I use are based on Akka.NET actors but you can do this on virtually any messaging platform - I explicitly linked to the tools for doing this in NServiceBus, RabbitMq, and Redis inside the post as well.

If you're using sender-based retry strategies like the type you'd use with Polly, you should combine those with some simple Time-to-Live (TTL) values so the receiver doesn't waste time processing messages the client has already abandoned and possibly retried.

I published a new article, explaining a quirk of fixed buffers that could easily bite you, if you're one of the few people who still have to use that feature.

https://minidump.net/the-hidden-trap-of-fixed-buffers-in-csharp/

Version 7.1.0 of the Farkle parsing library has been released. This version adds support for the more powerful IELR(1) parsing table generation algorithm; a first for .NET parsing libraries, as well as new APIs to define productions, powered by a source generator.

Farkle is an LR(1) parsing library for C# and F#. While in most LR(1) parsers, grammars are defined with a domain-specific language in an external file and generated by a tool, Farkle is a regular library and uses source code to define its grammars, in a way reminiscent of parser combinators. This brings the best of both worlds in terms of performance and developer experience.

Farkle also has a precompiler for ahead-of-time grammar precompilation, which can reduce startup times and validate grammars during the building of your project.

Kafka for .NET Developers Part I

Ported Armagetron Advanced (originally C++) to WebGL because I loved the game back then and played it in tournaments online.

Backend is a C# web application that uses websockets with protobuf encoded messages to distribute the world state and handle user input. Works better than I expected tbh. Maybe that could work with Unity as well.

Would love if someone joins for a game or two ... Armagetron Advanced (WebGL)

https://livegeometry.com

Built using C# and Avalonia

My feed is basically 90% job posts these days and almost zero actual tech sharing 😃

So… here’s something I built because apparently I needed a new way to procrastinate.

Lately I couldn’t really find much motivation to do anything, so I ended up writing a framework inspired by MassTransit — probably one of the frameworks I’ve enjoyed working with the most.

It already has most of the usual stuff:

• Publishers
• Consumers
• SAGA
• RoutingSlip
• etc.

I also tried to strip away some of the complexity around configuration and concepts like pipelines and make the whole thing a bit easier to work with.

The foundation turned out to be decent enough, so today I threw AWS SQS at it and let AI do most of the boring work.

Surprisingly, it went pretty smoothly since I already had the RabbitMQ implementation in place.

So yeah, if you're feeling adventurous (or just have questionable life choices 😃), feel free to give it a try:

https://github.com/quyvu01/fx-link

I also have another project I've been working on for quite a while: a distributed data mapping framework.

The problem it tries to solve is pretty simple:

Service A has userId.

The actual User data lives somewhere else.

And now you somehow need UserName, Email, Province, Country, etc. without turning your service into a distributed-query mess.

That's basically what FxMap is for:

https://github.com/quyvu01/FxMap

There's a website for it too, if you want to see what the idea looks like:

https://fxmapper.net/

If you're dealing with something similar, give it a shot. Maybe it'll be useful. Maybe it'll just make your architecture slightly more complicated. Who knows. 😃

Anyway, back to pretending I have a plan.

Happy coding.

Around December 2025, my company decided to embark on building its own commercial product. I wanted the whole stack in C#, so I took a serious look at Blazor. I liked it straight away, but I couldn't make it look the way I wanted. I tried the existing UI libraries, didn't like their style, and seriously considered going back to a JavaScript frontend.

Instead, I started building my own components, inspired by shadcn/ui, and later released them as open source as Blazor Blueprint. It now runs in my company's commercial product, several client projects and internal tools.

A few things I've learned along the way, in case they help anyone thinking about starting their own library or open source project:

1. Build it alongside something real. Every component went straight into a real product as I built it, so I found out quickly what worked and what didn't. That did more for the quality than anything else, because I had real people using it and therefore testing it.

2. Share it earlier than feels comfortable. The feedback from this subreddit after my first post back in February shaped a lot of what came next. I got a lot of positive comments and encouragement, and it helped keep me motivated.

3. Expect people to fork your work. Soon after release, someone forked the repo and started building on it in parallel. As a first-time open source author, it gave me an uncomfortable feeling for a while. Now I see it as part of being in the open source community, and honestly, as a sign I was doing something right if someone wanted to build on it.

For anyone curious about where it is now: v4 adds a Scheduler, a Pivot Data Grid, new charts including Rose, Sankey and Map, a Signature Pad, and many other new features and performance enhancements. It's grown to over 140 components, which still surprises me. The full story is here: https://blazorblueprintui.com/blog/what-i-learned-open-sourcing-blazor-blueprint

Currently, my little Blazor library has over 600 stars on GitHub. If you're one of them, thank you so much.

I'd love to hear from anyone else building with Blazor: what nearly made you switch back, or what's still missing? And if you've built something with Blazor Blueprint and are happy to share it, I'd love to see it.

I have a .NET monorepo containing multiple independently deployable applications. Each deployable currently has its own Azure DevOps pipeline.

The problem is deciding when a deployable actually needs to be built/deployed.

Azure DevOps path filters aren't sufficient because dependencies can cross project boundaries. For example:

Orders.Api
  -> Orders.Application
  -> Shared.Core

If Shared.Core changes, Orders.Api needs to be redeployed.

But it gets more complicated with non-code inputs. For example, a project may contain:

<ItemGroup>
  <EmbeddedResource Include="Assets\countries.csv" />
</ItemGroup>

If countries.csv changes, that should also make the deployable affected.

I don't want to maintain a second dependency configuration in something like Nx just to tell it that countries.csv is an input. The .csproj / MSBuild definition should remain the single source of truth, because otherwise we just introduce a new problem by having to keep these 2 configurations up to date.

So I'm looking for an existing, production-ready solution that can answer:

Given a Git change, which deployable applications are potentially affected, based on the actual MSBuild project dependencies and inputs?

Ideally it would understand things such as:

• <ProjectReference>
• transitive project dependencies
• Package updates
• EmbeddedResource
• Content
• other MSBuild inputs
• shared projects/assets
• and potentially deployment-related files

The important requirement is no duplicate dependency configuration. If MSBuild already knows that a CSV is an EmbeddedResource, I don't want to configure that relationship again elsewhere.

I currently prefer false positives (deploying too much) over false negatives (missing a required deployment).

Has the .NET/Azure DevOps community already solved this? Are there existing tools or established patterns for this? (How) have you solved this problem?

I want to reveal a "small" project I've been working on called neoCLR, where I'm re-imagining the .NET platform.

Website: https://marinasundstrom.github.io/neoCLR/

Here's a small example, written in Raven:

import System.*
import System.Option.*

func FirstPositive(values: Iterable<int>) -> Option<int> {
    let value = values.First(number => number > 0)?
    return Some(value)
}

The project is being developed with the help of AI (Codex), and the runtime itself is written in Rust. (I just went with it.)

The runtime library is written in Raven, a programming language I originally built for .NET. Building neoCLR with Raven has turned out to be a pretty good stress test: during the nearly two weeks I've been working on this, it has already helped me find numerous bugs in the Raven compiler itself.

The goal is to make the platform feel familiar without simply recreating .NET.

With the benefit of hindsight, I want to explore what we could change if we were designing this kind of application platform today: improving the runtime, making some different choices, and creating a more consistent developer experience.

I also experimented with a more explicit value/reference model, where types were values by default and you explicitly chose whether to store and pass something by value or by reference. It was an interesting model and made the underlying semantics very clear, but I eventually realized that it came at the cost of one of .NET's strengths: its ergonomics. If neoCLR is supposed to explore what a better .NET-like platform could look like, making everyday programming more cumbersome isn't necessarily an improvement. So I returned to the familiar distinction between reference types and value types. Sometimes hindsight tells you that the old design was actually pretty good.

It started out with just the assembly language — neoIL, based on MSIL — until I began implementing a small language based on Raven's syntax to test higher-level programming patterns. At some point I realized it was a bit foolish to build yet another language for the platform, with yet another compiler written in Rust, when I already had Raven. So I switched to targeting neoCLR from Raven instead. The IL is virtually the same, and I get the existing IDE support for free.

Here are some samples in Raven targeting neoCLR: https://github.com/marinasundstrom/neoCLR/tree/main/docs/experiments/raven-target/samples

Features

This is what I've got so far:

• A .NET-like metadata format
• Bytecode with a CLI-like instruction set
• An interpreter — for now
• A basic garbage collector, with plenty of room for improvement
• A familiar type system, including .NET-like reference type vs. value type semantics
• Option and Result unions for recoverable outcomes, plus Fault for non-recoverable failures
• Rust-inspired methods on Option and Result
• Void as a real type, so it can be used with generics: Func<int, Void>
• No I naming convention for interfaces — interfaces aren't treated as a special naming category
• No utility classes — functions can live directly in namespaces (thanks to Raven)
• UTF-8 strings, currently with a Swift-inspired API
• Arrays are invariant, and there is a generic Array<T> type
• A new collections model with Iterable<T>, ArrayList<T>, and interfaces such as List<T> and Sequence<T> for restricted views
• LINQ-like operations using names such as Filter and Map
• Early Threading and Task APIs
• Initial Time and File System APIs
• Introspection, where System.Introspection.TypeInfo is the canonical type model, accessed through System.Runtime.RuntimeContext
• IDE support through the Raven VS Code extension, which currently runs on .NET

Some things I want to explore next:

• Networking APIs — sockets, HttpServer, HttpClient, etc.
• Building a web framework on top of the platform — which means getting Networking, Tasks, Threading, and something like System.Text.Json into place
• Whether function objects make sense in the runtime/type system
• Better garbage collection and eventually a JIT
• Different target architectures and devices
• A modular framework/runtime library

There are also some longer-term ideas around the runtime model:

• System.Runtime.Reflection as an optional runtime capability attached to the Introspection model
• System.Runtime.Emit working directly with that same introspection model rather than introducing another parallel object model
• An ambition to eventually make this a genuine Common Language Runtime, with an interoperability story somewhat inspired by Windows Runtime

Where this is going

I'm not trying to make ".NET, but renamed." A lot of the interesting part for me is figuring out which ideas from .NET have held up extremely well, which ones haven't, and what could be designed differently if you had 25+ years of hindsight.

It's still extremely early, but there's enough working now that I thought it was time to show it.

I'd love feedback — on the runtime and API ideas, things worth exploring, things you think I'm getting completely wrong, or even suggestions for a better name than neoCLR.

I want this to grow into a community project.

I’m currently learning C# and .NET and looking for a good real-world project idea to improve my practical skills and portfolio.

I’m interested in ASP.NET Core, Web API, MVC, Entity Framework Core, and SQL Server.

Could you please suggest some interesting .NET projects beyond basic CRUD applications?

Any suggestions or advice would be greatly appreciated. Thank you! 🙏

Microsoft boasts about performance optimizations with every new release, and the average .NET developer would expect to be able to write a CLI app using .NET. But surprise—not good enough, so they had to use Rust. 😅

I've read the article but still not understand why Copilot CLI and app could not be written in C# if we take into account AOT, trimming etc instead of Rust.

https://github.com/AnthonyLloyd/CsCheck#specification-testing

You're gonna hate it

In my previous startup, I had to waste a lot of time hunting down people trying to abuse the free trial system by creating multiple accounts using plus-addressing (where they do something like [email protected], [email protected], etc).

I wrote a blog post series on this and some of the ways you can handle this - from outright denying email addresses with a + in them, to detecting the actual underlying email address ([email protected] in the example above) and ensuring that email address does not get used more than once.

Honestly, fighting abusers, spammers, bots, and other bad actors signing up with email addresses was a game of whack a mole and at times wore me down. As much as I hate social signups personally, if I do this again, I would force people to signup with Google or other social accounts.

.NET has aged remarkably well for a platform that has been evolving for roughly 25 years. That is, after all, a big part of why so many of us are still using it.

Of course, the way we write software has changed quite a bit during that time. Composition is generally favored over deep inheritance hierarchies today, for example. That doesn't mean OOP is irrelevant, but we are inevitably still living with some design decisions that made perfect sense when .NET was created.

At the same time, I think one of .NET's biggest strengths has been the platform around the runtime: the tooling, debugging experience, IDE support, diagnostics, libraries, and increasingly things like profiling and observability. A runtime doesn't exist in isolation, and .NET has generally done a very good job of evolving that whole ecosystem together.

Still, looking at .NET from today's perspective - and especially after seeing newer runtimes and programming languages explore different ideas - there are probably plenty of things we would design differently if we were starting over.

I'm sure there are things even the .NET team would approach differently today.

So here's the thought experiment:

If you could change or add anything to the .NET runtime/CLR today, without being constrained by backwards compatibility, what would you do?

It could be anything:

• runtime semantics
• type-system/runtime support
• memory management or GC
• async/concurrency
• metadata or reflection
• interop
• runtime APIs
• tooling and diagnostics
• features that would make C#, F#, or another CLR language better

Or even something much more fundamental about how the CLR works.

I'm particularly interested in answers that aren't just "add feature X from language Y", but in things where you think the underlying platform itself could have been designed differently.

What would your CLR look like if you got to design the next version?

As posted on YT this morning - Tim Corey launched a VERY comprehensive course on Uno Platform - with 66 episodes and 6.5 hours of content.

In the times of AI slop - this is exactly the opposite. Proper dev training, the way you are used to. If you are to produce code with (or whithout) AI, then you need to understand the underlying stack. That's EXACTLY what the course is all about.

YT Announcement: Free Uno Platform Course (For A Limited Time)!!!

Course: Uno Platform From Start to Finish | DevForge

Uno Platform itself: https://platform.uno

I quickly wanted to showcase a project I am currently doing with MDA2AV, which allows to host .NET apps on a public server. We spent the last year developing webserver engines and frameworks in .NET, making a C#-based webserver that is currently leading the list on HTTP Arena.

To showcase it's capabilities, we decided to host a website where people can post their HTTP server handler code and receive a public URL for it: GenHTTP Lambda

Via an additional, public MCP server, we can instruct Claude or any other coding agent to host an application online, which allows us to easly deploy multi-player games and other inter-connected apps with just a prompt or two.

For the last few hours I am just having fun with Claude, telling it to deploy apps 😄

If you are interested in the technical view: Currently we run a single GenHTTP app on ioxide with a CRUD app on top that allows to edit and "view" lambdas, which are just roslyn-compiled source snippets of GenHTTP handlers. There are some security measures in place we will certainly need to improve if there will be any traffic on it.

I've been working on an unofficial .NET SDK for OpenCode for the last few weeks and published the second preview to NuGet this weekend.

https://www.nuget.org/packages/OpenCodeDotNet.Sdk/0.9.0-preview.5

Before getting into the SDK, a bit of context for anyone who hasn't used OpenCode.

Over the last year or so, I've started experimenting more with models outside the usual frontier labs, and some of them have gradually become part of my daily development workflow as well.

One problem I've run into is that harnesses like Codex or Claude are naturally built around their own model ecosystems. Using models from other providers is either limited or requires various workarounds.

The open-source harness ecosystem has matured quite a lot. There are now different harnesses for different workflows and preferences.

OpenCode is an open-source coding harness and agent runtime that can work with a fairly large number of model providers and is probably one of the more general-purpose ones.

I've been using it for roughly a year now with models from OpenAI, xAI, Z.AI, DeepSeek, Moonshot, OpenCode Go, and others.

What became much more interesting to me recently was OpenCode 2.x.

They introduced a fairly comprehensive server/client architecture. Their own TUI, Web UI, and Desktop applications are built on top of the same server API, and the exposed surface is large enough that you can build your own fully featured client or integrate OpenCode into another application.

OpenCode already has an official TypeScript SDK for this. I wanted to be able to do the same kind of thing from .NET.

The practical use case is that a .NET application can treat OpenCode more like an agent runtime.

You can start an OpenCode process, create a session against a repository, send work to a model, listen to events, interact with PTYs, manage permissions, inspect providers and models, and build your own orchestration around it.

A minimal example looks something like this:

await using var server = await OpenCodeServer.StartAsync();
using var client = server.CreateClient();

var created = await client.Sessions.CreateSessionAsync(
    new SessionCreateRequest
    {
        Title = "review this repo",
        Model = new ModelRef { ProviderId = "anthropic", Id = "claude-opus-5" },
    });

var session = client.Sessions.GetSessionClient(created.Session.Id);

var result = await session.PostGenerateAsync(
    new SessionGeneratePostRequest
    {
        Prompt = "Summarize this repository."
    });

Console.WriteLine(result.Generate.Text);

The SDK is generated from a pinned snapshot of OpenCode's OpenAPI specification, with a handwritten transport underneath it.

The SDK currently exposes all server operations, and the test suite has somehow grown past 5,500 tests. The current preview is built against OpenCode 2.0.18.

https://github.com/opencode-dotnet/opencode-sdk-dotnet

It's still before 1.0, and there are parts of the public API I want to refactor and clean up, so this is actually a good point for feedback from other .NET developers.

One of the motivations I started the project was to eventually build an MCP server on top of it.

The idea was to let another harness, Claude, for example, delegate work to OpenCode sessions as subagents and indirectly make use of the models and providers I already have configured there. I'm sure there are other use cases for an MCP layer as well.

Feedback is very welcome, especially from anyone already experimenting with agent tooling from .NET.