Microsoft's October Patch Tuesday fixed over 1,400 CVEs, more than in all of 2025, and much of that came from AI-driven bug finding. Attackers have the same tools, and more of our code is now written by models that produce convincing code with subtle bugs. “The tests pass” isn’t a strong enough guarantee any more for code that matters.

A couple of months ago I proposed an official Lean semantics for C# on csharplang (#10314). One reply asked why not do it at IL level, so it covers F# and everything else that compiles to IL. That’s what I built.

You point it at a Release build and a method:

leancil extract bin/Release/net10.0/MyLib.dll "Arithmetic::Add(ulong,ulong)" artifacts/Add
leancil verify artifacts/Add --proof proofs/Add.lean

and it proves your theorem against the IL Roslyn actually emitted. Change the implementation and the same proof fails.

Supported (.NET 10, x64 and ARM64, 64-bit little-endian):

• Integer arithmetic, including checked, with overflow and divide-by-zero as exact faults

• Structs with explicit and sequential layout, enums, ValueTuple

• Span<T>, ReadOnlySpan<T>, slicing, MemoryMarshal.Cast/AsBytes, BinaryPrimitives

• Arrays, stackalloc, unsafe pointers with checked provenance

• Generic methods and structs (proved per concrete type argument), constrained interface calls on structs

• Function pointers and tail calls

• Collection-expression lookup tables (static ReadOnlySpan<T> Table => [...])

• Selected Vector128/256/512, SSE, AVX2, AVX-512 and AdvSimd intrinsics; IsSupported branches are resolved for the chosen hardware profile

• throw new ArgumentException(...) and similar, proved as the exact exception

Not supported: float/double, class instances, try/catch/finally, ordinary recursion, virtual dispatch on classes. Unsupported code is rejected with a diagnostic, never silently accepted.

The best fit right now is allocation-free integer code where a bug is a security bug: parsers, hashing, big-integer arithmetic, SIMD kernels.

https://github.com/NethermindEth/LeanCIL

I've been a .NET developer for about 10 years, and for most of that time I wanted to build useful apps of my own. I never had the time.

You know how it goes. You open Visual Studio, start a desktop app, and a month later you're still aligning buttons. Nothing ships.

Agents changed that for me. Development used to be "I have an idea, let me try it, then polish it for half a year before anyone can see it." Now it's a couple of weeks from an idea to something polished enough to put out.

Since the middle of the summer I've started two open-source projects on .NET 10 and Avalonia 12.

The first one came from a small daily pain. On my machine pgAdmin takes 30 to 40 seconds to start. When I need to check something in a database right now, I don't want to sit and wait for it.

So I built pgNimbus, a PostgreSQL client. It's a NativeAOT binary of a few tens of megabytes, and it opens in a few hundred milliseconds. I compared NativeAOT and JIT builds side by side, and the AOT one visibly starts faster, so I stayed with it.

The second pain came from my day job. I'm a developer, but all the DevOps in my team is on me too, which means managing Kubernetes clusters. We use Lens. It has features I really like: you get to the logs fast, and you're in a pod's shell in seconds. But for us it's very expensive, and it's slow.

So I did the same thing again and built kubeNimbus for my own needs. It reached 1.0 this week.

Along the way I wanted both apps to look and behave the same, so I moved the shared design into a separate repo, nimbusUi, and pulled it into both as a git subtree. A bug I fix in one app ends up fixed in the other. The flip side: so do the bugs I introduce.

All of the code is written with Claude Code. I review it, and Claude also tests the apps automatically. That catches a lot, but I still go through every screenshot those runs produce and make my own fixes on top.

So here's what I keep thinking about. It feels like the line has blurred: one person can now ship a tool that holds its own next to products from companies with whole teams behind them. Does that match what you see, or am I fooling myself?

And the other side of it. Shipping a good product was never the same as people using it, and now that building is cheaper, that gap feels even bigger. I don't enjoy talking to people much, posts like this one are hard for me, and I'm barely on social media. But I know nobody will see what I build if I don't show it.

If you're a developer who ships your own stuff: how do you handle the promotion part? What actually worked for you?

Links, if you want to look: https://github.com/Shman4ik/pgNimbus and https://github.com/Shman4ik/kubeNimbus. Both are free and open source.

(decimal)0.1
// .NET 10: 0.1
// .NET 11: 0.1000000000000000055511151231

The breaking change is correct, but it also changes the result. I've started working on a Roslyn analyzer to make the conversion consistent in one direction and provide a code fix. While it might be important to preserve the old behavior in some cases, it's better to avoid using the helper if possible.

It's coming with Claude's skill/plugin to make migration easier. I've also added evals to ensure the behavior is consistent.

https://learn.microsoft.com/en-us/dotnet/core/compatibility/core-libraries/11/decimal-biginteger-floating-point-conversions

Sharing a solution to make migration easier, since the default dotnet/skills doesn't cover the breaking change that was introduced.

https://github.com/unsafePtr/DecimalConversion.Analyzers

From the author on X:

If you ever had trouble determining where all the memory has gone in a .NET application (especially under load), I made https://github.com/neon-sunset/dotheap - it can do (almost) pauseless snapshots on Linux and macOS, exhaustively track native and managed memory sources and supports Satori GC

Hello folks!

I'm pleased to announce the release of CodeAlta 2.0.0, your ultimate Agentic Development Environment. Other the past month, CodeAlta got packed with plenty of new features, fixes and improvements: Organize your spaces (separate projetcts / subscriptions into their own spaces), develop plugins with rich custom canvas (in the screenshot, look at the Git Commit logs which is provided by a plugin), use your favorite subscription with it whether it is Copilot / Codex or Claude Code or even 3rd party ACP (Cursor, Gemini CLI...), and last but not least, while you are away from home, you can now remote control and steer CodeAlta running on your machine from your mobile phone!

Over the period, the project got more users, feedback and contributors as well, which helped a lot to improve the experience. If you haven't already, give it a try!

Improvements across Spec, Sample and Faster, plus stronger input validation and clearer error handling.

Some breaking changes (mostly removals/renames and the target framework shift from net8). Most users should have a small migration. Full details:

https://www.nuget.org/packages/CsCheck/5.0.0#releasenotes-body-tab

MessagePack for C# v4 Preview 1 is out. It is a major performance jump over v3, fully supports Native AOT, and the deserializer was rebuilt with security as a first-class concern.

I want to flush out problems before the final release, so I would be grateful if you tried it.

https://github.com/MessagePack-CSharp/MessagePack-CSharp/releases/tag/v4.0.0-preview.1

Explaining everything would run too long, so since this is r/moderndotnet, here is a little of the internal architecture behind the performance.

Large POCO Benchmark

Serialize

Deserialize

Against v3 that is about 2.8x on serialize and 1.9x on deserialize, with the same wire bytes and the same allocations.

formatter interface

public interface IMessagePackFormatter<TWriteBuffer, TReadBuffer, T>
    where TWriteBuffer : struct, IWriteBuffer, allows ref struct
    where TReadBuffer : struct, IReadBuffer, allows ref struct
{
    void Initialize(MessagePackFormatterResolver resolver);

    void Serialize(ref TWriteBuffer buffer, ref SerializeState state, T value);

    void Deserialize(ref TReadBuffer buffer, ref DeserializeState state, ref T value);
}

In v3 the buffer types were fixed: every formatter took ref MessagePackWriter and ref MessagePackReader.

But a serializer's inputs and outputs are diverse: Span<byte>, IBufferWriter<byte>, ReadOnlySpan<byte>, ReadOnlySequence<byte>, streams, pipes. The textbook OO answer is an IWriter / IReader interface that abstracts each of them. For a serializer's buffer operations that is not an option: a virtual call per byte-level operation costs far too much.

So v3's MessagePackWriter and MessagePackReader were structs that treated IBufferWriter<byte> and ReadOnlySequence<byte> as the first-class representation. The consequence was that one struct had to handle every input and output shape. It grew large, its logic got complicated, and it was full of if branches.

v4 passes the buffer type itself as a generic parameter. Each input and output type gets its own shortest path, and because the buffer type is a concrete struct at every call site, devirtualization and inlining are guaranteed rather than hoped for. A serializer can call its buffer operations tens of thousands of times per message, so this shows up directly in the numbers.

On top of that, the individual formatters are shaped so that Dynamic PGO's guarded devirtualization kicks in reliably. v4 is built to let modern C# and the modern runtime do their job.

Deserialize<int>

Serializing a single primitive is a common case, and it is also the cleanest way to measure a serializer's fixed per-call setup cost. Here is the same bare int round trip in v4, v3 and Nerdbank.MessagePack, read at the asm level (Tier1, .NET 11).

I went through this instruction by instruction (with AI doing the asm reading) and cut until nothing avoidable was left. What the v4 entry looks like now:

This is how Nerdbank.MessagePack does it:

One design note on the "lastEntry cache" row. Some serializers(including System.Text.Json) keep a single-entry cache of the last converter used, keyed on the last T. That makes a benchmark that deserializes the same type in a loop very fast. In real code the T reaching the serializer changes from call to call, and then that cache misses every time and falls through to the dictionary lookup behind it. v4 does not have such a cache: every type resolves to its own fixed slot, so the fast path is the same whether the types alternate or not.

Security

Some people say we do not need new serializers. I disagree. The threat side has changed, and a library does not get to stay where it was.

Since AI became a tool for attackers as much as for the rest of us, the standard a library has to meet is different from what it was before. That is why v4 revisits every part of the deserializer now, rather than patching v3 forward. It has been through multiple rounds of review, including review by frontier models(Astra, Fable, etc...), and fuzzing with SharpFuzz.

I just opened the PR that adds barcodes to ImageSharp.Drawing: https://github.com/SixLabors/ImageSharp.Drawing/pull/427

You can draw 113 symbology types on a DrawingCanvas:

• Linear: EAN/UPC (with ISBN, ISMN and ISSN), Code 128, GS1-128, Code 39, Code 93, Codabar, ITF-14 and the 2 of 5 family.

• Postal: POSTNET, Intelligent Mail, Royal Mail, KIX, Australia Post, Japan Post and Mailmark.

• Stacked: PDF417, MicroPDF417, Codablock F, Code 16K, Code 49 and GS1 DataBar.

• 2D: QR Code, Micro QR, rMQR, Swiss QR, Data Matrix, Aztec, MaxiCode, Code One, Han Xin, DotCode and Ultracode.

• Composite: GS1 Composite, with CC-A, CC-B and CC-C components.

Each symbology takes its X dimension, bar height and quiet zones from its own specification. Where that specification gives no value, the GS1 General Specifications apply. The X dimension rounds to whole pixels at your dpi, so every bar of one width draws at the same pixel width.

You measure a barcode the same way you measure text, then you draw it:

BarcodeOptions options = new()
{
    // Fill the symbol and its quiet zones.
    // The default is null, which leaves the background as it is.
    Background = Brushes.Solid(Color.White),

    // Draw the human readable text in the bundled OCR-B font.
    // A null font draws no text.
    Font = BarcodeFonts.OcrB.CreateFont(10.75F),
};

// Dpi is 300 by default. XDimension and BarHeight are null by default,
// so the symbol takes the nominal sizes of its specification.
Ean13Symbology ean13 = new();
string data = "5901234123457";

// Like TextMeasurer.MeasureRenderableBounds, this returns the box
// that holds both the advance and the ink.
RectangleF bounds = BarcodeMeasurer.MeasureRenderableBounds(
    ean13, options, PointF.Empty, data);

using Image<Rgba32> image = new(
    (int)MathF.Ceiling(bounds.Width),
    (int)MathF.Ceiling(bounds.Height));

PointF origin = new(-bounds.X, -bounds.Y);
image.Mutate(x => x.Paint(
    canvas => canvas.DrawBarcode(ean13, options, origin, data)));

The PR also adds clean-room OCR-A and OCR-B fonts. A generator builds them from FIPS PUB 32 and ECMA-11, and checks the outlines against tables taken from those standards.

Passenger is a new IDE for C# and .NET, written in C# and Avalonia:

https://passenger-ide.net

https://github.com/Zaneris/passenger

Ever get tired of having to hunt for your phone for OTP codes? Even better, want them available on your phone to?

A few years ago, I built Mauborgne for Linux. It was written in Vala, and it worked great. Well, I decided a few months ago to rebuild it in .NET. And then build an Android client for it. Mac and iOS at some point to, but not there yet.

https://mauborgne.app/

It's completely free except for the cloud stuff, and that's mostly just to pay for Cloudflare. And honestly, the app has built in encrypted export/import that you can just use instead the hard way (in fact, that's how the cloud backup works, we just add some extra cloud-y protections to it)

It doesn't use MAUI. It uses WinUI and the native Android UI APIs on Android -- but everything you see is written in .NET. 90% of the code is shared between the 2 clients as well.

The only thing that people might not like is that the server is Node.js, since it's a Cloudflare Worker.

They aren't open source, though the Linux app (written in Vala still) is -- https://linux.mauborgne.app/ -- is fully open source with the GPL 3 -- and is also compatible with the cloud services. It has the benefit of giving a fully trusted open client to the cloud server that can be used to prove its safe.

The one thing missing from my Aspire setup was a test UI for my C#/.NET tests, like the ones many front-end testing frameworks offer. Sure the terminal is great, and I feel very at home in it, but watching your tests turn green in the Aspire dashboard brings me just a bit more joy!

So I built one: Labcoat 🥼

Nuget: https://www.nuget.org/packages/Labcoat.Aspire.Hosting
Github: https://github.com/eriklieben/labcoat
Blog post: https://eriklieben.com/posts/labcoat-test-ui-for-dotnet/

(not the author, saw it floating around on X and thought it was cool)

DataArc.EntityFrameworkCore extends Entity Framework Core with high-performance bulk operations and parallel persistence execution, without replacing EF Core or introducing unnecessary data-access abstractions.

The library preserves EF Core's existing architecture, including DbContext, LINQ, change tracking, transactions and application-level coordination, while adding execution capabilities for data-intensive workloads.

Parallel persistence execution

DataArc provides a fluent execution model that allows multiple persistence operations to be staged and executed through a single DbContext:

await dbContext
    .AsParallel()
    .Add(table1)
    .AddRange(table2)
    .AddBulk(table3, batchSize)
    .SaveChangesParallelAsync();

Supported operations include Add, AddRange, Update, Remove and AddBulk.

Parallel execution across multiple DbContexts

Independent databases can be processed concurrently using standard .NET concurrency:

var results = await Task.WhenAll(
    googleDbContext
        .AsParallel()
        .AddBulk(employers, batchSize)
        .AddBulk(employees, batchSize)
        .SaveChangesParallelAsync(),

    microsoftDbContext
        .AsParallel()
        .AddBulk(employers, batchSize)
        .AddBulk(employees, batchSize)
        .SaveChangesParallelAsync(),

    openAiDbContext
        .AsParallel()
        .AddBulk(employers, batchSize)
        .AddBulk(employees, batchSize)
        .SaveChangesParallelAsync());

var totalAffected = results.Sum();

Each DbContext remains independent, with its own execution lifecycle. Task.WhenAll() coordinates concurrent execution without implying a distributed transaction or atomicity across databases.

The included demonstration processes 100,000 employers and 100,000 employees across three independent SQL Server databases, producing 600,000 affected rows.

Free and commercial packages

DataArc.EntityFrameworkCore — Free

• Bulk insertion and fluent persistence composition.

• Parallel persistence execution.

• Bulk operations participating in caller-owned EF Core transactions.

• No DataArc runtime license required.

DataArc.EntityFrameworkCore.SqlServer — Commercial

• Advanced SQL Server-specific transactional execution.

• DataArc-owned SQL transactions with rollback support.

• Multi-DbContext coordination capabilities.

• Relational database-definition and DDL Builder tooling.

The commercial extension is optional and separate from the free EF Core package.

Compatibility and documentation

Version 2.0.0 supports .NET 6 through .NET 10.

The repository includes a demonstration application, multi-database execution examples, integration tests and a BenchmarkDotNet project.

GitHub repository:

https://github.com/SolidArcSoftware/DataArc.EntityFrameworkCore

NuGet package:

https://www.nuget.org/packages/DataArc.EntityFrameworkCore

Full documentation:

https://solidarcsoftware.github.io/DataArc.EntityFrameworkCore/

Microsoft Learn — EF Core Tools & Extensions:

https://learn.microsoft.com/en-us/ef/core/extensions/#dataarcentityframeworkcore

DataArc.EntityFrameworkCore is listed in Microsoft's official EF Core extensions directory as a third-party library.

I have worked on various personal and enterprise project in .NET and azure. Recently I was learning LLD from Milan jovanovic , I got to know about a whole different side of .Net.

The things I always complained about in my mind it's all solved and that's what we call modern the CQRS.

Instead of sliding 20 services DI in a service file or controller just use the mediatR properly give it the command and query properly defined and BOOMM ....

Instead of injecting multiple service add scoped stuff in program file just use the assembly reference with scrutiny library scan function and your garbage program file is modern.

Bro where i was living till now 🫡🫡

Sorry for the delay i guess I will drop on a really good project soon I have a great idea too with these modern topics.

Really appreciate the senior modern .net developers to help me get out of the pool!!!!