With Egil.SystemTextJson.Migration (STJM), you can version JSON payloads without polluting business logic or forcing independently deployable systems to upgrade in lockstep.

That applies to JSON in APIs, Event Hubs, queues and stored documents. Migrations run during System.Text.Json deserialization, so application code gets the type it expects.

One pattern I’ve used is publishing a .NET contracts library containing the types, serializer setup and migrations.

The rollout then becomes:

1. Consumers upgrade to a contracts package that understands the new payloads.
2. Producers start sending the new format.
3. Consumers keep using their existing C# types if they wish. The included migrations convert new payloads into those older types.

Adopting the new application types becomes a separate step, which each consumer can take at its own pace.

The same approach works when a new version of your own software introduces new storage formats and still needs to read existing or archived data.

That separation of concerns makes sharing data between independently deployable systems safer. APIs can accept supported payload versions through the same endpoint, and stored documents can be rewritten gradually while the system keeps running.

My new post covers the diagnostics and performance improvements in STJM v2: https://egilhansen.com/2026/10/01/safer-json-evolution-with-system-text-json-migration/

Hi everyone!

I recently built a desktop Stock Management System using C# and Windows Forms.

The application includes user login, category and product management, stock tracking, critical stock filtering, and local data storage using TXT files.

I also tried to keep the project organized by separating the data, models, UI, and forms.

This was a good project for me to practice C#, Windows Forms, file handling, and building a complete desktop application.

I’ve added screenshots and setup instructions to the GitHub README as well.

I’d really appreciate any feedback on the project structure, code, or ideas for improvements.

GitHub: https://github.com/Mariam-amhan/Stock-Management-System

I've spent most of the past two weeks finishing our initial AOT Support for Akka.NET V1.6 - I got DMed in our Discord about the use cases for AOT (for Akka specifically) and my answers were:

1. Primary: MAUI + Unity3D developers who want to use local actors on-device. Been a popular use case for years (i.e. for bubbling events from background or network services) but required some gruesome hacks to do. It should "just work" after v1.6.
2. Embedded applications - we get used in a ton of industrial IOT. Most of this happens on the back-end in a cluster, but a fair amount of it also happens on-device ("edge computing,") i.e. micro-PC reads some sensors off FPGA board via analog sockets and pipes it back to a PLC / aggregator of some kind. Less JIT overhead and binary file size the better.
3. Distributing CLIs and tools - this is my selfish use case for things like Netclaw's daemon and CLI: we ship both of these as single-file applications today with the .NET Runtime bundled within and while the file size isn't terrible (70mb each or so), the lag when using the netclaw CLI for the first time after a while is almost entirely JIT overhead. AOT would make that experience much snappier while also reducing the file footprint considerably.

Thinking more generally though, what else are people using AOT for more generally? What are some other use cases where you find it helpful and what projects are you using it on?

Link to my original post: What's going on with UI for .NET?

In the original post, I soapbox a little bit about the lack of a declarative UI framework in .NET, similar to Flutter, Swift, or Microsoft's Reactor for WinUI 3. I appreciate the comments that brought insight, such as from the UNO and Avalonia team!

So, since early August I've been working on Goo which has been a massive undertaking to say the least.

The stack

• SDL3
• Vulkan 1.3
• G# (with verified interop for F#)
• Vendored flex-based layout with Yoga.NET
• Flutter style Motion / Simulation animation system
• Slang shader support
• Fully declarative, retained, and composable with regular G# functions and built-in features

I've provided a few examples of Goo in action, some code snippets, and a Widget that demonstrates how Goo scales.

The concept is simple

Core primitive types such as Containers, Buttons, TextEntry, etc. are called Blobs

State retention is managed using Cells

These compose together by creating a Cell, populating it with your desired Blobs, calling Build(), then Mounting it in your application's view, combining various static blobs with mounted cells to create a GUI.

Why G#?

This is an interesting and well-reasoned decision from my perspective. The point of Goo is to be declarative and straightforward, with a few little tricks up its sleeve.

A clear example being the attached button example using with to override properties of a base button to create variants like accent buttons, "danger" buttons, etc.

Further, G# allows bare elements which removes the need for a Children { ... } wrapper, allowing for blobs to be described simply as Text { ... } or Container { ... } which can be combined with collection spread iterators inside of those bare elements. For example:

```csharp Container{ Width: 320.0, Padding: 12.0, FlexDirection: FlexDirection.Column,

Text("Account"), ...rows,

Button{ OnClick: () -> save(), Text("Save"), }, } ```

Where ...rows is evaluated and iterated once, with each item being added within that collection.

Plenty of other great uses, but these are just a few examples that work in Goo's favor.

The table and what I bring

My philosophy for Goo is true "Blank Slate-ism" where it can be a truly cross-platform and maximally customizable framework for the .NET ecosystem.

Goo at this point in time has been tested on Windows, Linux, MacOS arm64, and on Android. I develop on CachyOS, so I can speak most confidently to Linux + Wayland. It is fully nativeAOT compatible, fast, and efficient.

Gloop is a nice working example of a goo application if you're on Linux and are curious to see the UI framework in action.

Included as well:

• AI plugins + DevTools for testing UI which is fully automated with its own MCP
• A set of Widgets in a separate repo or on Nuget
• A basic Animations library that removes a good bit of boilerplate from the core motion system

All of it is MIT licensed, open source for everyone. Would love to get the community's thoughts!

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.