.NET

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.

TL;DR: We're making free Community editions of all our Accelerate tools available to every developer. Starting September 2025, you'll get professional-grade XAML editing, dev tools, and later our visual designer, and packaging capabilities at no cost.

When I created the !dotnetmaui@programming.dev Community, I was strongly encouraged to cross-post here. Fast-forward to now and we are getting the same or more engagement on the original posts there than the cross-posted content here, so I'm going to break free from the mothership now and stop cross-posting. To continue to get MAUI content make sure to follow and/or subscribe to the MAUI Community.