How Microsoft is actually evolving .NET: performance, developer experience, and AI

I have been paid to write C# since Framework 4.x felt like the only adult Microsoft runtime. I have also left .NET for Go for a few years and come back to a stack that is not the one I abandoned. The evolution I actually use is not a keynote about copilots in Visual Studio. It is a faster GC, a publish model that can be native, a C# that got less ceremonial, and a cross-platform runtime that no longer feels like a dare. The AI features are the part I still treat as optional chrome.

This is how I see Microsoft moving the platform in 2026 — performance, DX, and the assistant layer — and which of those I would take on a new service tomorrow.

Performance: the part I can measure

.NET 6 through 9 (and the 10-era bits landing as I write) kept doing the unsexy work: JIT improvements, PGO, better span usage in the BCL, a GC that is less of a stop-the-world story for a lot of web apps. I have moved an API from Framework-on-IIS to .NET 8 on Kestrel on Linux and watched p99 drop without a rewrite of the domain. That is the evolution I will praise in a meeting. It is not a rewrite. It is a runtime upgrade with a punch list: packages, nullable, a hosting model.

Native AOT is the sharper tool. I have published a worker as a native binary when cold start was the product — a queue consumer on a scale-to-zero host. The constraints are real: trim warnings, reflection, some libraries that still assume a fat JIT world. I would use AOT for a CLI and for a function. I would not AOT a giant ASP.NET app that lives for weeks and uses every half of the BCL. The keynote will blur those. I will not.

ASP.NET Core minimal APIs plus source generators (regex, JSON, logging) are the DX-that-is-also-perf story. I like them when the app is a set of endpoints. I still use controllers when the app is a forest of filters and conventions the team already knows. I will not rewrite a controller app into minimal APIs to feel contemporary. I will take the JSON source generator on the hot path.

I still read BenchmarkDotNet before I believe a tweet about allocations. Microsoft’s own blogs are better than they used to be about showing the benchmark. I still run mine on our payload.

Developer experience: C#, the SDK, and the editors

C# 10–13 made the language I wanted in 2016: records, pattern matching that is actually pleasant, global usings I use sparingly, required members, raw string literals for the SQL I still write. Nullable reference types are the feature I now require on a new project. They are also the feature that makes a Framework port loud for a month. I want the loud month. I do not want the null I used to ship.

The SDK and dotnet CLI are how I live on a Mac and on Linux without pretending csproj is a ritual. Central package management, a Directory.Build.props that is not a junk drawer, and a solution that builds in CI the same way it builds on my laptop — that is DX. Visual Studio is still the debugger I miss when I am in VS Code / Rider / Cursor. Rider is the IDE I actually enjoy. VS Code plus C# Dev Kit is fine for small services. I will not pick an editor to please Redmond.

MAUI and Blazor are the DX Microsoft wants to talk about. I have shipped Blazor Server for an internal admin and liked the model. I have been cautious about Blazor WASM payload size for a public site. MAUI I would only pick if the team is already C# and the app is not a consumer fashion piece. I would still tell a consumer-mobile team to look at the native stacks or at Flutter/RN depending on hiring. That is not a slam. It is a hiring graph.

Aspire (the orchestration / app model story) is the interesting DX bet for a distributed .NET shop: run the pieces together locally without a novel docker-compose folklore. I have used it on a sample. I would adopt it when we have more than two processes and a backlog of “works on my machine.” I would not adopt it to add a dashboard to a single API.

AI: what I will turn on, and what I still do not trust

GitHub Copilot in the IDE is useful the same way it is useful in any language: boilerplate, a test I can edit, a LINQ I would have written in three minutes. I use it. I do not trust it with a migration, with a crypto call, or with “just wire up Identity.” I read the diff. I have watched it invent an EF configuration that looked right and ignored a unique index we needed.

Microsoft’s broader pitch — copilots in Visual Studio, agents that can edit a solution, Azure-hosted models in the product — is a vendor story I treat as a preview. I will not architect a product around a preview control in the IDE. I will not put customer data into a Microsoft AI feature because the checkbox was on by default. That is the same rule I have for every vendor assistant. The brand does not change the data path.

Semantic Kernel and the various “build an agent in .NET” libraries are fine if I am already on Azure and I want an orchestration I can read in C#. I have also used Python for the same job. I pick the language the evals and the team already run. I do not pick Semantic Kernel to be loyal. I do not trust any of these stacks to have a stable API next year. I keep the domain out of them. The agent is an adapter. The invoice rules stay in a project that does not import a model SDK.

IntelliCode-style completions and “explain this” in the editor are DX. They are not a runtime feature. Mixing them in a keynote with “.NET is faster” is how you get a confused roadmap. I separate the slides when I plan a quarter: runtime upgrade is one bet. Assistant licenses are another. They do not share a success metric.

What I would do on a Framework estate, and on a greenfield

Framework estate: move to .NET 8 LTS (or the current LTS when you read this) on Linux if you can, stay on Windows if the dependencies are Windows. Kill WebForms when you have a reason, not as a purity project. EF Core is not EF6; budget the LINQ differences. This is still worth it. I have done it. The performance story is the executive slide. The real win is a platform that still gets security patches and a hiring pool that is not “people who remember WebForms.”

Greenfield API in a Microsoft shop: .NET current LTS, minimal APIs or controllers, EF Core or Dapper/sqlc-shaped SQL for the hot queries, OpenAPI, a health check, OpenTelemetry. I would not start on Framework. I would not start on .NET just to use Copilot. I would start on .NET because the org is C#, the identity story is Entra ID, and the library for the boring enterprise thing exists.

Greenfield outside a Microsoft shop: I would still pick .NET if the team is C# and happy. I would pick Go or the shop’s language if they are not. Loyalty to Microsoft is not a strategy. The evolution of the runtime is a reason to stay if you are already staying. It is not a reason to convert a Rails team.

The through-line I actually believe

Microsoft is evolving .NET the way a mature platform should: make the default server faster, make the language less noisy, make Linux normal, offer a native publish for the cold-start crowd, and bolt assistants onto the editor because that is the market. I will take the first four on purpose. I will take the fifth with a review process and a data-handling rule.

I have also watched F# stay excellent and stay niche. I would still write F# for a domain that wants types first. I would not sell a rewrite to F# as the Microsoft evolution story. The evolution story is C# getting closer to that voice, plus a runtime that does not need Windows to feel official.

I still do not trust an AI feature that wants to “fix” a solution while I am not looking. I trust dotnet test, a benchmark, and a trace. That trust is older than Copilot. It is also why the performance work matters more to me than the keynote. Faster bits and a clearer language change the code I ship. A chat panel changes the way I draft. I know which one I will fund first when the budget is one engineer-quarter. I will spend that quarter on the LTS bump before I spend it on a new chat panel.