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.

about the new and interesting changes and additions in .NET networking space. This time, we are writing about HTTP improvements, new web sockets APIs, security changes and many distinct additions in networking primitives.

AI models have a knowledge cutoff and do not have access to your personal or company data by default.

While context engineering is a broader topic, this post will focus on enabling access to high-quality data through data ingestion pipelines.

… we’re excited to announce the preview release of data ingestion building blocks for .NET.

… how these building blocks empower the .NET ecosystem to build composable data ingestion pipelines for their AI applications.

What's new in .NET 10

Central to Copilot Studio’s innovation is its deep integration with .NET, including the use of .NET on WebAssembly (WASM).

This post explores how Copilot Studio utilizes .NET, the benefits realized from platform upgrades, and the resulting performance, cost, and productivity improvements.

Copilot Studio is a low-code experience for creating conversational and autonomous agents, but the runtime executing those agents is based on .NET.

Four more days until dotnet 10 release. Are you excited?

I am. There's always a ton of new things, some quite pleasant and exciting to use. C# extension usually have the biggest impact on me. This time, I'm excited for

• Null-conditional assignment
• Simple lambda parameters with modifiers
• field backed properties

Last week I tried/had to try RC2 and assess release notes for changes because [developing and] debugging Blazor WebAssembly in dotnet 9 is bothersome. I wasn't successful in making the switch, but I found a service worker registration bug fix noted with "should also be applied to dotnet 9 projects" which solved the biggest issue for now (deployed app not updating).

I'm still concerned about the Blazor WebAssembly tech complexity and indirection (we're working on an offline-capable website/PWA), but I'm somewhat hopeful dotnet 10 will improve working with and on it a bit.

We are setting up a new project right now, where we want to implement Messaging. We usually would just add MassTransit and call it a day. Since they went commercial, we are asking ourselves the quests if there is still a need for Messaging Frameworks, or if a self written RabbitMQ implementation is good enough for most cases?

What are your opinions on that?

Are you still using a Messaging Framework, if so which one are you using and why?

Or are you just writing your own implementation with RabbitMQ, if so do you see any problems with that approach?