You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: release-notes/10.0/preview/preview6/aspnetcore.md
+44-56Lines changed: 44 additions & 56 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -22,17 +22,17 @@ ASP.NET Core updates in .NET 10:
22
22
23
23
## Automatic eviction from memory pool
24
24
25
-
The memory pools used by Kestrel, IIS, and HTTP.sys now automatically evict memory blocks when the application is idle or under less load, helping applications use resources more efficiently.
25
+
Memory pools used by Kestrel, IIS, and HTTP.sys now release unused memory when applications are idle, improving resource efficiency.
26
26
27
27
**Why it matters:**
28
-
Previously, memory allocated by the pool would remain reserved, even when not in use. With this enhancement, when the app is idle for a period of time, memory is now released back to the system, reducing overall memory usage and helping applications stay responsive under varying workloads.
28
+
Previously, pooled memory stayed reserved even when unused. Now memory is automatically returned to the system during idle periods, reducing overall memory usage.
29
29
30
30
**How to use:**
31
-
No action is needed to benefit from this feature. Memory eviction is handled automatically by the framework.
31
+
No action needed. This works automatically.
32
32
33
-
There are also metrics added to the default memory pool used by our server implementations. The new metrics are under the name `Microsoft.AspNetCore.MemoryPool`. See the [ASP.NET Core metrics documentation](https://learn.microsoft.com/aspnet/core/log-mon/metrics/metrics) for general information on what metrics are and how to use them.
33
+
There are also metrics available for the memory pool under the name `Microsoft.AspNetCore.MemoryPool`. See the [ASP.NET Core metrics documentation](https://learn.microsoft.com/aspnet/core/log-mon/metrics/metrics) for more information.
34
34
35
-
You can also use the new `IMemoryPoolFactory` service interface to create or access memory pools for custom scenarios:
35
+
You can create custom memory pools using the new `IMemoryPoolFactory` service interface:
@@ -73,17 +67,16 @@ public class CustomMemoryPoolFactory : IMemoryPoolFactory<byte>
73
67
{
74
68
publicMemoryPool<byte> Create()
75
69
{
76
-
// Return a custom MemoryPool implementation or the default.
77
-
returnMemoryPool<byte>.Shared;
70
+
returnMemoryPool<byte>.Shared; // or custom implementation
78
71
}
79
72
}
80
73
```
81
74
82
75
## Blazor WebAssembly preloading
83
76
84
-
Blazor now provides a `<LinkPreload />` component to generate`link` tags instead of using link headers to preload framework assets. This allows the framework to correctly identify the Blazor application base URL and provides better control over the preloading behavior.
77
+
Blazor now provides a `<LinkPreload />` component that generates`link` tags for preloading framework assets instead of using link headers. This gives better control over preloading behavior and correctly identifies the application's base URL.
85
78
86
-
To use this feature, place the `<LinkPreload />` component in the head of your application:
79
+
To enable preloading, add the `<LinkPreload />` component to your application's head:
87
80
88
81
```diff
89
82
<head>
@@ -93,50 +86,46 @@ To use this feature, place the `<LinkPreload />` component in the head of your a
93
86
</head>
94
87
```
95
88
96
-
Removing the component will disable the preloading feature, which is useful in cases where the application uses the `loadBootResource` callback to modify URLs.
89
+
Remove the component to disable preloading, which is useful when using the `loadBootResource` callback to modify URLs.
Set the new `WasmBundlerFriendlyBootConfig` MSBuild property to `true` to make the Blazor WebAssembly build output compatible with tools like webpack or rollup.
93
+
Make Blazor WebAssembly compatible with JavaScript bundlers like webpack or rollup by setting the `WasmBundlerFriendlyBootConfig` property to `true`.
Setting this property will adjust the .NET boot configuration to explicitly import framework assets. The output won't be directly runnable in the browser, but the project's published out can be consumed by JavaScript bundlers to combine it with other scripts.
101
+
This adjusts the boot configuration to explicitly import framework assets. The output won't run directly in browsers but can be consumed by JavaScript bundlers.
109
102
110
103
## Improved form validation for Blazor
111
104
112
-
Blazor now has improved form validation capabilities including support for validating properties of nested objects and collection items.
105
+
Blazor now supports validating nested objects and collection items in forms.
113
106
114
-
To create a validated form, use a `DataAnnotationsValidator` component inside an `EditForm` component, just as before. To opt into the new validation feature, do the following:
107
+
To use this feature:
115
108
116
-
1. Call the `AddValidation` extension method in your application setup.
117
-
2.Declare the form model types in a .cs file (i.e., not a .razor file).
118
-
3.Annotate the root form model type with the `[ValidatableType]` attribute.
109
+
1. Call `AddValidation()`in your application setup
110
+
2.Create model types in .cs files (not .razor files)
111
+
3.Add the `[ValidatableType]` attribute to your root model type
119
112
120
-
Without these steps, the validation behavior remains the same as in previous versions where only the top-level type is validated.
113
+
Without these steps, validation works the same as before (top-level only).
121
114
122
-
Note that the `[ValidatableType]` attribute is currently experimental and is subject to change, so using this attribute will result in a build error. You'll need to suppress this diagnostic to try out the feature.
115
+
**Note:** The `[ValidatableType]` attribute is experimental and causes a build error. Suppress the diagnostic to use this feature.
123
116
124
-
Here's an example:
117
+
Example:
125
118
126
119
```csharp
127
120
// Program.cs
128
121
varbuilder=WebApplication.CreateBuilder(args);
129
122
builder.Services.AddRazorComponents();
130
-
131
-
// This line enables the new validation behavior.
132
-
builder.Services.AddValidation();
123
+
builder.Services.AddValidation(); // Enable new validation behavior
133
124
```
134
125
135
126
```csharp
136
127
// Data/OrderModel.cs
137
128
138
-
// This attribute is needed on the top-level model type.
139
-
// The other types are discovered automatically.
140
129
#pragmawarningdisable ASP0029 // Type is for evaluation purposes only and is subject to change or removal in future updates. Suppress this diagnostic to proceed.
141
130
[ValidatableType]
142
131
#pragmawarningrestore ASP0029 // Type is for evaluation purposes only and is subject to change or removal in future updates. Suppress this diagnostic to proceed.
The requirement to declare model types outside of `.razor` files is due to the fact that both the validation feature and the Razor compiler use source generators. Currently, output of one source generator cannot be used as input for another source generator.
172
+
Model types must be in .cs files because validation uses source generators, and one source generator's output can't be input for another.
185
173
186
174
## `NavigationManager.NotFound()` works after streaming has started
187
175
188
-
Calling `NavigationManager.NotFound()` now works even when streaming a response has already started. This improvement allows for better error handling in scenarios where content has already begun streaming to the client, but a not found condition is later encountered.
176
+
`NavigationManager.NotFound()` now works even after response streaming begins, enabling better error handling when content has already started streaming but a not found condition occurs later.
189
177
190
178
## Blazor diagnostics improvements
191
179
192
-
All Blazor Server traces are now top-level activities, instead of being nested under HTTP or SignalR parent activities. This simplifies looking at Blazor Server traces in diagnostic tools like the .NET Aspire developer dashboard or in Application Insights.
180
+
Blazor Server traces are now top-level activities instead of being nested under HTTP or SignalR activities. This simplifies viewing traces in diagnostic tools like the .NET Aspire dashboard or Application Insights.
193
181
194
-
Additionally, the `CircuitStart` trace has been moved to a separate `Microsoft.AspNetCore.Components.Server.Circuits` source.
182
+
The `CircuitStart` trace moved to a separate `Microsoft.AspNetCore.Components.Server.Circuits` source.
Blazor Server apps now persist the declared state of circuits before evicting them from memory. When a client reconnects after a prolonged period, the app can restore the circuit state, allowing users to resume their work uninterrupted.
196
+
Blazor Server apps now persist declared circuit state before evicting circuits from memory. When clients reconnect after extended periods, apps can restore circuit state, letting users resume their work uninterrupted.
209
197
210
198
**Why it matters:**
211
-
Previously, when a circuit was evicted due to memory pressure or other factors, all client state would be lost. Users would have to start over, losing their progress and creating a poor user experience. With state persistence, applications can now maintain continuity even when circuits need to be temporarily removed from memory.
199
+
Previously, circuit eviction meant losing all client state. Users had to restart, losing progress and creating poor experiences. State persistence maintains continuity even when circuits are temporarily removed from memory.
212
200
213
201
**How it works:**
214
-
Circuit state is persisted either in memory or using `HybridCache` if configured for the app. Only declared state is persisted.
202
+
Circuit state persists in memory or using `HybridCache` if configured. Only declared state is persisted.
215
203
216
-
You can also implement custom policies for persisting and evicting circuits using the new `Blazor.pause()` and `Blazor.resume()` JavaScript APIs. These APIs allow you to control when circuits are paused and resumed based on your application's specific needs. For example, you might choose to pause circuit when the circuit is idle, when the server is about to restart, or when the browser tab isn't currently visible to the user. When the circuit is paused, it is persisted to the client to free up server resources.
204
+
You can implement custom policies using the new `Blazor.pause()` and `Blazor.resume()` JavaScript APIs. These control when circuits pause and resume based on your needs. For example, pause when idle, during server restarts, or when browser tabs aren't visible. Paused circuits persist to the client, freeing server resources.
217
205
218
-
The following example shows how you might pause the app when it isn't currently visible and then resume it when it becomes visible again to save on server resources:
206
+
Example - pause the app when hidden and resume when visible to save server resources:
219
207
220
208
```javascript
221
-
// Pause the circuit when the tab becomes hidden
209
+
// Pause when tab becomes hidden, resume when visible
## Disabling `NavigationException` usage is now opt-in
232
220
233
-
To improve backwards compatibility, disabling usage of `NavigationException` for Blazor page navigations is now opt-in. The configuration switch has been renamed and its default value updated:
221
+
To improve backwards compatibility, disabling `NavigationException` for Blazor page navigations is now opt-in. The configuration switch was renamed with an updated default value:
The Blazor Web App template has been updated to disable the use of `NavigationException`so that navigation behavior across render modes is more consistent for new Blazor apps.
228
+
The Blazor Web App template disables `NavigationException`usage for more consistent navigation behavior across render modes.
241
229
242
230
## Add passkey support to ASP.NET Core Identity
243
231
244
-
Passkeys are a modern, phishing-resistant authentication method that improves security and user experience by leveraging public key cryptography and device-based authentication. ASP.NET Core Identity now supports passkey authentication based on the WebAuthn and FIDO2 standards. This feature allows users to sign in without passwords, using secure, device-based authentication methods like biometrics or security keys.
232
+
ASP.NET Core Identity now supports passkey authentication based on WebAuthn and FIDO2 standards. Passkeys provide a modern, phishing-resistant authentication method using public key cryptography and device-based authentication, allowing users to sign in without passwords using biometrics or security keys.
245
233
246
-
The Blazor Web App template provides out-of-the-box passkey management and login functionality.
234
+
The Blazor Web App template includes built-in passkey management and login functionality.
247
235
248
-
Developers can use new APIs to enable and manage passkey authentication in existing apps.
236
+
Developers can use new APIs to add passkey authentication to existing applications.
249
237
250
238
## Minimal API validation integration with `IProblemDetailsService`
251
239
252
-
Error responses from the validation logic for minimal APIs can now be customized by an `IProblemDetailsService` implementation provided in the application services collection (DI container). This enables more consistent and user-specific error responses in an ASP.NET Core application.
240
+
Minimal API validation error responses can now be customized using an `IProblemDetailsService` implementation in the services collection (DI container). This enables more consistent and user-specific error responses.
253
241
254
242
Community contribution from [@marcominerva](https://github.com/marcominerva). Thank you!
255
243
256
244
## Validation APIs moved to extensions package
257
245
258
-
The validation APIs have been moved to the `Microsoft.Extensions.Validation` namespace and NuGet package, making them usable outside of ASP.NET Core scenarios. The public APIs and their behavior remain the same, just under a new package and namespace. Existing projects should not require code changes; old references will redirect to the new implementation. The APIs have also been marked as experimental as they are subject to future changes.
246
+
The validation APIs moved to the `Microsoft.Extensions.Validation` namespace and NuGet package, making them usable outside ASP.NET Core scenarios. The public APIs and behavior remain the same, just under a new package and namespace. Existing projects should work without code changes as old references redirect to the new implementation. The APIs are marked as experimental and subject to future changes.
0 commit comments