Route parameters with non-string values fails

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

In .NET 8 preview 5, when creating a SSR Blazor app and using route parameters with e.g. int type, the page fails to load with an error: InvalidCastException: Unable to cast object of type ‘System.String’ to type ‘System.Int32’.

Here is the component I used to test this:

@page "/counter/{currentCount:int?}"
<p role="status">Current count: @CurrentCount</p>
@code {
    [Parameter] public int CurrentCount { get; set; }
}

I tried this on .NET 7 Blazor WASM app and it worked.

Expected Behavior

When going to an url https://localhost:7208/counter/5 the CurrentCount property should be set to 5.

Steps To Reproduce

Create a .NET 8 Blazor SSR app, copy the code to a Counter.razor component and navigate to it’s url.

.NET Version

8.0.100-preview.5.23303.2

[javiercn]

@Markz878 thanks for contacting us.

Yes, this seems to be a bug (more of an integration issue).

@surayya-MS @SteveSandersonMS this is very likely a difference between asp.net core routing and Blazor routing.

Blazor will use the constraints to cast the value to the proper type, while ASP.NET Core won’t do so.

I suggest two possible action plans:

• Process the parameters inside Router to convert the string to the appropriate type.
• Update RouteView to do this casting instead (since it knows the parameter types).
• Convert route values into cascading parameters and implement [SupplyParameterFromRoute].

[mkArtakMSFT]

We’ve discussed this offline and decided to go with the following approach. As a short-term mitigation we will make so that the client router will ignore the server router logic completely for now.

In parallel, we will see if we can bring the missing features to the routing system, so that this scenario works properly. If we manage to do that before rc2 and we are happy with the approach, we will take that and remove the temporary fix. Otherwise, we will come up with the proper fix in .NET 9, leaving the simple workaround in place in .NET 8.

//cc @SteveSandersonMS , @javiercn, @surayya-MS