Update the "What's new in ASP.NET Core 9.0" for .NET 9 Release Candidate 1

[danroth27]

Description

Update the "What's new in ASP.NET Core 9.0" for .NET 9 Release Candidate 1

Page URL

https://learn.microsoft.com/en-us/aspnet/core/release-notes/aspnetcore-9.0?view=aspnetcore-8.0

Content source URL

https://github.com/dotnet/AspNetCore.Docs/blob/main/aspnetcore/release-notes/aspnetcore-9.0.md

Document ID

4e75ad25-2c3f-b28e-6a91-ac79a9c683b6

Article author

@Rick-Anderson

[BrennanConroy]

Keep-Alive Timeout for WebSockets

The WebSockets middleware can now be configured for keep alive timeouts.

The keep alive timeout will abort the WebSocket and throw from WebSocket.ReceiveAsync if a ping frame from the websocket protocol is sent by the server and the client doesn't reply with a pong frame within the specified timeout. The ping frame is automatically sent by the server and configured with KeepAliveInterval. This option is useful when wanting to detect connections that might be slow or ungracefully disconnected.

The keep alive timeout can be configured globally for the WebSocket middleware:

app.UseWebSockets(new WebSocketOptions { KeepAliveTimeout = TimeSpan.FromSeconds(15) });

Or configured per accepted WebSocket:

app.Run(async (context) =>
{
    using var webSocket = await context.WebSockets.AcceptWebSocketAsync(
        new WebSocketAcceptContext { KeepAliveTimeout = TimeSpan.FromSeconds(15) });

    // ...
}

[BrennanConroy]

Keyed DI in Middleware

Middleware now supports Keyed DI in both the constructor and the Invoke/InvokeAsync method.

private class MyMiddleware
{
    private readonly RequestDelegate _next;

    public MyMiddleware(RequestDelegate next, [FromKeyedServices("name")] IService service)
    {
        _next = next;
    }

    public Task Invoke(HttpContext context, [FromKeyedServices("obj")] IRequestService requestService) => _next(context);
}

See Write custom ASP.NET Core middleware for more information on writing custom middleware.

Thanks to NicoBrabers for this contribution!

[MackinnonBuck]

Override InputNumber type attribute

The InputNumber component now supports overriding the type attribute. For example, you can specify type="range" to create a range input that supports model binding and form validation:

<InputNumber type="range" min="1" max="10" step="1" @bind-Value="Model.Rating" />

Thanks for the contribution, MattyLeslie!

In case we want a more detailed example:

<EditForm FormName="BlazorSurvey" Model="Model">
    <DataAnnotationsValidator />
    <ValidationSummary />

    <div>
        <label for="rating">Rate how awesome this feature is (1 to 10)</label><br />
        <InputNumber id="rating" type="range" min="1" max="10" step="1" @bind-Value="Model!.Rating" />
    </div>

    <button type="submit">Submit</button>
</EditForm>

@code {
    [SupplyParameterFromForm] BlazorSurvey? Model { get; set; }

    override protected void OnInitialized() => Model ??= new();

    class BlazorSurvey
    {
        [Required, Range(minimum: 10, maximum: 10, ErrorMessage = "The rating must be 10.")]
        public int Rating { get; set; }
    }
}

[danroth27]

From @JamesNK:

Improvements to SignalR distributed tracing

.NET 9 preview 6 added initial support for SignalR distributed tracing. RC1 improves SignalR tracing with new capabilities:

• .NET SignalR client has an ActivitySource named "Microsoft.AspNetCore.SignalR.Client". Hub invocations now create a client span. Note that other SignalR clients, such as the JavaScript client, don't support tracing. This feature will be added to more clients in future releases.
• Hub invocations on the client and server support context propagation. Propagating the trace context enables true distributed tracing. It's now possible to see invocations flow from the client to the server and back.

Here's how these new activities look in the .NET Aspire dashboard:

[wadepickett]

Just a side-note on process:
We have live changes and reviews going on async in both dotnet/release-notes-draft and here in this docs version.

I do not suggest we have to figure it out now for this release, but it seems like at some point we could do this all one place with one source (and perhaps, even one publication) for the same audience.

Here are some things I see happening:

• Duplication of effort.
• Reviews and edits happening asynchronously in both places.
• The source of the most recent truth gets a bit fuzzy.

It is a process that inherently invites some problems that might be avoided.

[amcasey]

dotnet dev-certs https --trust on Linux

On Ubuntu and Fedora, dotnet dev-certs https --trust will now configure trust of the self-signed development certificate in Chromium (Edge, Chrome, Chromium, etc) and Mozilla (Firefox, etc) browsers, as well as in dotnet (HttpClient, etc). Previously, --trust only worked on Windows and macOS.

[I believe the docs changes are staged but not live.]
[There are mode details here.]

[wadepickett]

Improvements to SignalR distributed tracing ...

I will combine this new SignalR Client ActivitySource with the existing section we have for the SignalR Hub ActivitySource as two sub-sections to a SignalR ActivitySource section. (Unless that isn't wanted.)

[danroth27]

I will combine this new SignalR Client ActivitySource with the existing section we have for the SignalR Hub ActivitySource as two sub-sections to a SignalR ActivitySource section. (Unless that isn't wanted.)

@wadepickett Yup, that's the intent. The What's New doc should be a full aggregation of the new features. It doesn't need to capture every delta along the way - that's what the preview release notes are for.