@hellfirehd thanks for contacting us.

Unfortunately, its likely not possible we can do this without significant changes into how the Razor compiler works which this issue alone might not merit the investment.

Pages use string literals because that information gets embedded in several places and is used for several checks. In addition to that, Razor lacks a semantic understanding of the C# code at compile time and it is impossible for it to resolve the constant value to perform the tasks it has to during compilation.

We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.

I like example above. But anything is better than magic string, even something so simple like this:

public static class Routes
{
  public const string Route1 = "/Hello";
  public const string Route2 = "/World/Hi";
}

@page Routes.Hello

Comments written above is correct - it is HARD to maintain this system with magic string. And I find so many times debugging difficulties. With constants it will be better.

Pages use string literals because that information gets embedded in several places and is used for several checks. In addition to that, Razor lacks a semantic understanding of the C# code at compile time and it is impossible for it to resolve the constant value to perform the tasks it has to during compilation.

Could you allow it to be set from the Code Behind?

My issue was closed, as were similar ones over the years. There seems to be resistance to this, but I don't know how it can be justified. Managing something as complicated as routes with the current approach is difficult.

There are all sorts of workarounds on SO ([1], [2]) but none is perfect. It needs to be baked into the compiler/runtime.

Could you allow it to be set from the Code Behind?

That would be fine by me too, but would make assets double in size as we'd need two files for every routable component. There are some examples in those links above. And something like this would be nice too, which effectively places the compile-time constant in the generated codebehind:

@page @ROUTE
@functions { public const string ROUTE = "/Foo"; }     // can reference this const from other code

ok, what is the status of this? it was created in 2021.

• Allow Varible Parameter For Blazor @page Directive aspnetcore#28827
• @page directive: allow string constant aspnetcore#23958
• Support variable for Blazor @page directive declaration aspnetcore#25589
• Mention @attribute [Route()] As A Dynamic Alternative to @page AspNetCore.Docs#27262
• Blazor @page directive remove requirement for string double quotes (RZ1016) aspnetcore#44352
• string constant for @page directive aspnetcore#23195
• Accept @page routing and navigation with const string aspnetcore#17500
• Blazor - Support @Page static value directive aspnetcore#14098
• [Blazor] Allow to reference constant field in @page directive aspnetcore#13453
• [Feature Request] Remove magic strings from RazorPages routing aspnetcore#41930
• [Blazor] strongly defined page path and also default page path aspnetcore#41827
• ...

@wstaelens Like I said above, this goes back years. There has been resistance to handling it for technical reasons (understandable...), but it's strange given how important this is. Especially given this is c# after all.

I find it staggering that this has not been addressed. A const string is pretty much a string literal anyway. If Razor lacks a semantic understanding of the C# code why not run a pre-processor that runs through and replaces the constants before compiling? There's already something like that happening with the source generated in _razor.g.cs. (Sometimes compile errors refer to these files only which can be very difficult to fix, but that's another issue.)

You can probably just add a Route attribute manually, either from razor file, or from codebehind
@attribute [Route(UrlConst)]

That trick may work for razor components, but not for razor pages. None of the workarounds here or the SO questions I linked above work for Razor Pages.

Please consider this for v9.

This works for RazorPages:

@page
@attribute [RazorCompiledItemMetadata("RouteTemplate", MyConstants.Pages.Foo.Bar)]

But that is unnecessarily complicated, and still has a magic string in it. A better syntax is needed.

+1 to get this done; it conveniently enables declaring your route strings once in the entire application, especially making it easier for parameterless routes.

It's been 4 years since a member said that the compiler infrastructure would need to undergo critical changes to support this feature. Is the status at least any better now to support making this change within a short timeframe without fearing breaking the entire infrastructure?

I had a look at the compiler and I believe it won't require too significant changes. Is it okay if I gave it a go and submitted a PR if it's a manageable case?

yes please @Rekkonnect !

@Rekkonnect If you want to submit a PR for this, we'd be happy to review it! Thanks!

Hi everyone, is there an update for this? We would love to see this resolved especially since there is a waiting PR for it.

Hey I'd love to have the PR merged too; check this comment for more info:
#11805 (review)

Basically the required change would introduce a new kind of token in the language, which is not a decision you can make on the spot so it's being internally discussed. We should be getting an update on this matter within the next few weeks from what I estimate, but I'm not an official source.

On the upside, if this new token kind gets approved, even with modifications, it opens up new possibilities with reducing the usage of @() expressions in other directives, by enabling them to accept simpler and intuitive expressions directly into the syntax. This will be a recurring matter outside the scope of this issue. I'd be glad if those changes got through and we get more QoL improvements like this one in other directives.