.NET 11 for Web Applications: What Matters for Enterprise Projects

At Accso, we have spent more than two decades helping clients across Germany and internationally build software that keeps up with changing business and technology needs. From Darmstadt to Cape Town, our teams work across industries, time zones, and technology stacks. A significant part of that work runs on Microsoft’s .NET platform.

So when a new version of .NET arrives, we do not just scan the release notes and move on. We look at what has changed, what is useful now, what still needs careful evaluation, and what it could mean for the systems we build and maintain with our clients.

.NET 11 brings several important improvements for web applications, especially around Blazor, Minimal APIs, OpenAPI, and real-time communication. This post highlights the changes we believe are most relevant for our clients and how we are thinking about them in practice.

A quick note on our .NET practice

Some of our longest-standing client relationships are built on .NET. Enterprise back ends, public sector portals, industry platforms, internal business tools, and customer-facing applications all benefit from .NET’s long-term reliability and strong ecosystem.

At Accso, we believe good software should be built to last. That means we do not adopt new platform features simply because they are new. We evaluate them carefully, test them in the right context, and use them where they create real value.

With that in mind, here is what stands out in .NET 11 for web projects.

Blazor continues to mature

Blazor allows teams to build interactive web interfaces using C# and .NET. It has been growing steadily over the past few releases, and .NET 11 adds several improvements that make it more practical for real-world applications.

If you are already using Blazor, or considering it for a future project, this release is worth paying attention to.

Forms become more practical in static rendering scenarios

One of the most useful improvements is client-side validation support for static server-side rendering forms.

In earlier versions, static SSR forms often needed a server round trip before users received validation feedback. That is not ideal for modern web applications, where users expect immediate responses while filling in forms.

In .NET 11, static SSR forms can provide instant validation feedback in the browser when using the supported validation setup. The important part is that the validation rules still come from the .NET model. This helps avoid duplicating validation logic in JavaScript.

For clients with form-heavy applications, such as onboarding flows, data entry portals, customer self-service tools, or multi-step processes, this can improve the user experience while keeping the implementation cleaner.

.NET 11 also adds support for asynchronous form validation scenarios. This is useful when validation needs to check something outside the current form, for example whether a username already exists or whether a reference number is valid. Microsoft notes that the full built-in async DataAnnotations experience depends on additional APIs, so this is an area we would evaluate carefully before using it broadly in production.

State management gets easier in static SSR

.NET 11 also improves how temporary and session-based data can be handled in Blazor static SSR applications.

• TempData support makes it easier to show one-time messages after a redirect. A typical example would be showing “Your form was submitted successfully” after a user completes an action.
• Session data persistence allows values such as shopping cart IDs or multi-step form progress to survive across requests. This is useful for applications where users move through a process over several pages.

These features were possible before with custom approaches. Having clearer platform support should reduce custom code and make implementations easier to reason about.

Navigation becomes less error-prone

The new RelativeToCurrentUri option for NavigateTo and NavLink allows navigation relative to the user’s current page path instead of always navigating from the application root.

This may sound small, but it matters in applications with deeply nested routes. These are exactly the kinds of small framework improvements that prevent subtle bugs and reduce friction for development teams.

QuickGrid becomes more useful for real applications

QuickGrid, Blazor’s built-in data grid component, receives several practical improvements in .NET 11.

• Pagination and sorting state can now be reflected in the URL. This means users can bookmark a specific page, share a sorted view with a colleague, or use the browser back button without losing their place.
• Row click events are now supported through OnRowClick. This makes it easier to build common interactions, such as clicking a row to open a detail page.
• Multiple grids on the same page are also better supported, as long as each grid that needs independent query string state is configured with its own QueryParameterNamePrefix.

For clients with dashboards, administration tools, reporting interfaces, or operational portals, these improvements can make a noticeable difference.

Blazor WebAssembly publish output can be smaller

.NET 11 includes trimming improvements that can reduce the published size of Blazor WebAssembly applications, especially when the app does not use OpenTelemetry or Hot Reload-related functionality in production.

Smaller downloads can improve first-load performance. This matters for users everywhere, but especially in regions or environments where bandwidth is less predictable.

Minimal APIs become more consistent

Minimal APIs are a lightweight way to build HTTP endpoints in .NET. They are often useful for smaller services, focused APIs, or projects where a full controller-based approach is not necessary.

.NET 11 improves how Minimal APIs behave when parameter binding fails.

Previously, if a request had invalid or missing parameters, the endpoint filter pipeline could be skipped and the framework would return a basic 400 response. In .NET 11, endpoint filters can observe parameter-binding failures when filters or filter factories are configured.

This matters because many projects use filters to standardise error responses. For API consumers, consistent error messages are not just a nice detail. They make APIs easier to integrate with, test, and support.

There is one technical note here: in Development environments, teams may need to configure ThrowOnBadRequest so that the framework returns a 400 response the filter can observe instead of throwing an exception.

C# union types become available in supported web scenarios

.NET 11 introduces C# union types, and the .NET web stack supports them in places where System.Text.Json is used. This includes JSON request and response bodies in Minimal APIs and MVC, SignalR’s JSON protocol, Blazor JavaScript interop, persistent component state, and prerendered component parameters.

Union types allow developers to model values that can be one of several shapes. This can make some APIs and message contracts clearer.

There is one important limitation: union types are not supported for non-body binding sources such as route values, query strings, headers, and form fields.

OpenAPI support becomes more accurate

OpenAPI documentation is often the contract between teams. It is used by front-end developers, integration partners, testing tools, code generators, and support teams. When the generated documentation does not match the real API behaviour, friction follows.

.NET 11 improves OpenAPI generation in several useful ways.

• It can generate OpenAPI 3.2.0 documents when configured to do so. This keeps API descriptions aligned with newer specification capabilities.
• File responses are also described more accurately. Endpoints returning binary content, such as generated documents or downloads, can now be represented with binary schemas such as type: string and format: binary, provided the endpoint metadata is set appropriately.
• Enum handling has also improved. Non-body enum parameters now better reflect actual .NET binding behaviour, even when JSON serialisation uses a naming policy. This reduces the gap between what the documentation says and how the API behaves.

Real-time and server-side Blazor scenarios get more control

For applications that use real-time functionality, .NET 11 adds more configuration options in server-side Blazor scenarios.

The new ConfigureConnection option for Interactive Server components gives access to underlying SignalR connection settings that previously required workarounds. This includes settings such as closing connections when authentication expires, enabling stateful reconnects, and tuning buffer sizes.

.NET 11 also adds a server-triggered circuit pause capability for server-side Blazor apps. This allows the server to ask connected clients to begin a graceful pause flow. It is useful for planned maintenance, deployments, and instance draining, where the goal is to avoid abruptly interrupting active users.

What this means for your projects

If you are an existing Accso client on .NET

The changes in .NET 11 are evolutionary rather than disruptive. That is good news. Some improvements may apply with little code change. Others will need configuration, testing, or careful rollout.

We will evaluate these features project by project. Where we see a clear benefit, such as better form validation, improved grid navigation, smaller WebAssembly output, or cleaner API documentation, we will raise those opportunities during roadmap and architecture discussions.

If you are evaluating Accso or considering a new .NET project

.NET continues to strengthen as a platform for modern web applications. Blazor is becoming more capable, Minimal APIs are becoming more consistent, OpenAPI support is more accurate, and server-side real-time scenarios are gaining better operational controls.

For organisations that value a unified technology stack, strong tooling, and long-term maintainability, .NET remains a very strong choice.

Our commitment

At Accso, in Germany and in Cape Town, we build software that is meant to last. That means staying close to platform developments, but also being honest about when to adopt new features and when to wait.

.NET 11 brings meaningful improvements for web projects. We are excited about several of them, and we look forward to applying them where they create real value for our clients.

This article references Microsoft’s official release notes for web development features in .NET 11: learn.microsoft.com.