.NET

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?

Today we are excited to announce the new NuGet.org Sponsorship feature which makes it easier than ever for consumers to recognize and support the authors behind their favorite packages.

Approved sponshorship platforms: GitHub Sponsors, Patreon, Open Collective, Ko-fi, Tidelift, Liberapay

[…] We are announcing the .NET Security Group, a group of organizations that will collaborate on delivering security fixes to the broadest set of .NET users, simultaneously with Microsoft. We’re all better served by getting more deployments patched, quickly and predictably.

We’re believers in the concept of upstream open source projects. That includes sharing vulnerability information with other organizations that distribute .NET. We’ve done that with a small set of companies since 2016, starting with Red Hat. Members receive source patches prior to public disclosure so that binary packages can be built, validated, and published at the same time as Microsoft. Membership of this group has been private, by invitation only, and grew to include Canonical, IBM, Red Hat, and Microsoft. That’s how the .NET Security Group started.

We are expanding the program to enable organizations that ship their own distribution of .NET to have the same ability to better protect their users. By sharing information about vulnerabilities with trusted partners early, we hope to reduce the time between public disclosure of CVEs and when updates are available for distributions other than Microsoft’s. We believe this will help strengthen the security of the .NET ecosystem.

[…] Several Linux distributions do this, as do independent software vendors (across both Windows and Linux). In fact, we worked in collaboration with these same organizations to reduce the cost of building .NET, resulting in the dotnet/dotnet repo. We want it to be straightforward and low-cost to distribute security fixes to users.

More recently, other organizations came to us asking if they could get access to patches for their End-of-Life servicing businesses. These requests made us realize that it was time to publicize the .NET Security Group and better define its goals. Program members need to be active participants in the .NET upstream project and publish builds for supported .NET versions. Doing that demonstrates a strong commitment to the ecosystem and earned credibility to all participants.

This month you will find that these CVEs have been fixed:

• GC: Garbage Collector manages the allocation and release of memory for your application
• DATAS: Dynamic Adaptation To Application Sizes

In .NET 9 we enabled DATAS by default. But .NET 9 is not an LTS release so for many people they will be getting DATAS for the first time when they upgrade to .NET 10. This was a tough decision because GC features are usually the kind that don’t require user intervention — but DATAS is a bit different. That’s why this post is titled “preparing for” instead of just “what’s new” 😊.

I’ll talk about how we generally decide which performance features to add, why DATAS is so different from typical GC features, and the tuning changes introduced since my last DATAS blog post. I’ll also share two examples of how I tuned DATAS in first-party scenarios.