I wrote a blog post about me getting in to FSharp web application development, but am having issues deciding how I want the data access to look. I'm very much open to feedback!

I kept running into the same issue when writing integration tests for ASP.NET Core APIs — there’s no clean way to assert how many SQL queries an endpoint executes.

Most of the time it ends up being:

• custom DbCommandInterceptor
• wiring it into WebApplicationFactory
• manually counting queries

So I wrapped that into a small library.

Example:

await using var guard = factory.TrackQueries<Program, AppDbContext>();

var client = guard.CreateClient();

await client.GetAsync("/api/orders");

guard.AssertCount(exact: 1);

That’s it — no manual interceptor or log parsing.

What it does:

• Counts SELECT/INSERT/UPDATE/DELETE queries triggered by HTTP requests
• Starts counting from CreateClient() (so startup/seeding queries are ignored)
• Works with any EF Core provider
• Designed for WebApplicationFactory-based integration tests

GitHub: https://github.com/KiwiDevelopment/KiwiQuery

NuGet: dotnet add package KiwiQuery.EFCore

MIT, very small codebase. Would love feedback — especially if you’re already solving this in a different way.

A pull request for the Microsoft .NET Runtime build on Linux to use IO_uring for sockets is showing some massive performance benefits.

Ben Adams of Illyriad Games and a .NET contributor opened the pull request to use IO_uring for sockets on Linux. This implementation is a complete, "production grade" IO_uring socket I/O engine for .NET's System.Net.Sockets layer. With the proposed code it's currently opt-in via the OTNET_SYSTEM_NET_SOCKETS_IO_URING=1 environment variable.

cross-posted from: https://mander.xyz/post/46588897

In our previous post “Reinventing how .NET Builds and Ships”, Matt covered our recent overhaul of .NET’s building and shipping processes. A key part of this multi-year effort, which we called Unified Build, is the introduction of the Virtual Monolithic Repository (VMR) that aggregates all the source code and infrastructure needed to build the .NET SDK. This article focuses on the monorepo itself: how it was created and the technical details of the two-way synchronization that keeps it alive.