MapDynamicControllerRoute doesn't work with DefaultLinkGenerator #16965

ollieferns · 2019-11-11T08:19:24Z

Describe the bug

The DefaultLink Generator (and the AnchorTagHelper) do not work when mapping dynamic routes. They do not find any routes and produce a null href.

To Reproduce

create a vanilla mvc site
add one dynamic route
use the anchor tag helper or the LinkGen class
Result is href is null.

see v simple example here.

https://github.com/ollieferns/dynamiclinkgenissue

Further technical details

ASP.NET Core version 3.1 (preview)
.NET Core SDK (reflecting any global.json):
Version: 3.1.100-preview2-014569
Commit: 4bd5d24d87

Runtime Environment:
OS Name: Mac OS X
OS Version: 10.15
OS Platform: Darwin
RID: osx.10.15-x64
Base Path: /usr/local/share/dotnet/sdk/3.1.100-preview2-014569/

Host (useful for support):
Version: 3.1.0-preview2.19525.6
Commit: 5672978d91

.NET Core SDKs installed:
3.0.100 [/usr/local/share/dotnet/sdk]
3.1.100-preview1-014459 [/usr/local/share/dotnet/sdk]
3.1.100-preview2-014569 [/usr/local/share/dotnet/sdk]

.NET Core runtimes installed:
Microsoft.AspNetCore.App 3.0.0 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 3.1.0-preview1.19508.20 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 3.1.0-preview2.19528.8 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.NETCore.App 2.1.13 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
Microsoft.NETCore.App 3.0.0 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
Microsoft.NETCore.App 3.1.0-preview1.19506.1 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
Microsoft.NETCore.App 3.1.0-preview2.19525.6 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]

javiercn · 2019-11-11T11:36:08Z

@ollieferns thanks for contacting us.

@rynowak can you look into this?

oferns · 2019-11-13T20:28:21Z

@javiercn @rynowak I cloned the source and had a look. The issue appears to me to be in RouteValuesAddressScheme around line 104

var metadata = endpoint.Metadata.GetMetadata<IRouteNameMetadata>();

Because the endpoint is a IDynamicEndpointMetadata not a IRouteNameMetadata it doesnt consider the route. I made IDynamicEndpointMetadata inherit from IRouteNameMetadata as a fix. It fixed my issue but made 3 tests fail. If I get to the bottom of the issue, how would I go about submitting a PR? I would rather like this fixed. In the meantime, what is the best way of referencing my altered MVC assemblies instead of the default ones for my own project?

oferns · 2019-11-15T09:55:49Z

Hi, any chance of a quick answer to this while the issue is being looked at?
" In the meantime, what is the best way of referencing my altered MVC assemblies instead of the default ones for my own project?"

Is there an easy way to do this? Or do I need to add the MVC projects to my solution?

Thanks,
O

ollieferns · 2019-11-26T12:31:54Z

@rynowak @javiercn could I get a response to my questions at least if there is no progress? thanks

ollieferns · 2019-12-09T13:21:38Z

@rynowak @javiercn could somebody reach out to me please regarding this issue. It seems to me to be a fairly serious issue with endpoint routing. Happy to discuss privately if required but the total radio silence is a bit unnerving when trying to convince my powers-that-be that .net core and aspnet is a viable technology choice for what we are trying to do here.

oferns · 2020-03-17T12:00:59Z

So as an update this still does not work in .NET 5.01 Preview. How depressing. No answers to my questions for 4+months and no fix.

MaxHorstmann · 2020-05-18T10:45:19Z

Same issue here, see Stack Overflow. Is there an update? Would a PR for this be considered?

mkArtakMSFT · 2020-05-26T23:41:33Z

Thanks for suggesting help, @MaxHorstmann.
It's not clear at the moment what the fix would look like here as we haven't yet investigated this.
@javiercn do you have something on mind about this for @MaxHorstmann to consider?

JeremyCaney · 2020-08-17T03:48:34Z

I’m really glad to hear that this is being evaluated for .NET 5.0.0. In the meanwhile, at minimum, it’d be useful to acknowledge this limitation in the documentation. It took me a bit to isolate this behavior and discover this issue.

(If I have a chance, I can look into submitting a PR for the documentation—though I’ll need to investigate the conventions for documenting feature limitations, as I’m not clear how that’s generally handled.)

The existing `MapTopicAreaRoute()` extension method recently introduced (6c6ad74) requires, at minimum, an `areaName` parameter, and thus is limited to setting up routes for one individual area at a time. This extension doesn't (currently) accept any parameters, and will instead map _all_ areas to support the `{**path}` catch-all expected by the OnTopic CMS. It does this by implementing the new `TopicRouteValueTransformer` (865f26a) to automatically set the `controller` and the `rootTopic` routing variables to the `area` name, which is the convention we most frequently follow. As part of this, I also registered `TopicRouteValueTransformer` with ASP.NET Core dependent injection, as part of the `AddTopicSupport()` extension. Be aware that this implementation trips of a feature limitation of ASP.NET Core 3.0 which prevents e.g. `@Url.Action()` references from correctly returning values (see dotnet/aspnetcore#16965). Hopefully that will be resolved in ASP.NET 4.0.

…l areas The existing `MapImplictAreaControllerRoute()` extension method recently introduced (8a65c95) requires, at minimum, an `areaName` parameter, and thus is limited to setting up routes for one individual area at a time. This extension doesn't (currently) accept any parameters, and will instead map _all_ areas. It does this by implementing the new `TopicRouteValueTransformer` (865f26a) to automatically set the `controller` routing variable to the `area` name, which is the convention we most frequently follow. Be aware that, as with the recently introduced `MapTopicAreaRoute()` (762d229), this implementation trips of a feature limitation of ASP.NET Core 3.0 which prevents e.g. `@Url.Action()` references from correctly returning values (see dotnet/aspnetcore#16965). Hopefully that will be resolved in ASP.NET 4.0.

ghost · 2020-10-09T17:47:56Z

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.

enricoe73 · 2021-07-05T21:39:20Z

Hello, any news on this ? It's not woking also for razor pages with
endpoints.MapDynamicPageRoute and the tag helper ( asp-page-handler attribute)
@mkArtakMSFT

ghost · 2021-08-10T18:02:05Z

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.

oferns · 2021-08-10T19:26:01Z

(facepalm)

thilap-web · 2021-09-21T10:19:55Z

any workarounds on this ?

rjgotten · 2021-11-08T16:00:48Z

any workarounds on this ?

You have to glue your own link generation into things. To make it work you have to overwrite the default registered address schemes used by the link generator with versions that can handle whatever kind of link generation you need. GetPathByAction is implemented as an extension method on top of GetPathByAddress so you can't override it with a custom implementation directly, you have to go through the whole address scheme pipeline instead.

(I've written it myself before, but it's closed source company code. Having to write it that way blows, to say the least.)

Note also that the whole URL generation pipeline running through LinkGenerator and the address schemes is synchronous through-and-through. So if you need to pull data from a database at any one point -- which is not entirely unthinkable for data-driven localized URL generation -- you have to settle for blocking operations.

ghost · 2022-10-12T18:22:55Z

Thanks for contacting us.
We're moving this issue to the .NET 8 Planning milestone for future evaluation / consideration. Because it's not immediately obvious that this is a bug in our framework, we would like to keep this around to collect more feedback, which can later help us determine the impact of it. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

javiercn added area-mvc investigate labels Nov 11, 2019

mkArtakMSFT assigned rynowak Nov 11, 2019

mkArtakMSFT added this to the 5.0.0-preview1 milestone Nov 11, 2019

mkArtakMSFT added the feature-routing label Nov 11, 2019

mkArtakMSFT modified the milestones: 5.0.0-preview1, next sprint planning Jan 10, 2020

t-val mentioned this issue Feb 14, 2020

Support Dotnet core 3 mariuszkerl/AspNetCoreSubdomain#61

Closed

mkArtakMSFT unassigned rynowak May 18, 2020

mkArtakMSFT assigned javiercn May 26, 2020

mkArtakMSFT mentioned this issue Jul 2, 2020

Improvements to DynamicRouteValueTransformer #21471

Closed

This was referenced Aug 21, 2020

Upgrade to ASP.NET Core 3.0 saaratrix/asp.net-core-mvc-localized-routing#36

Open

[Suggestion] Make DefaultLinkGenerator public and non sealed #25121

Open

javiercn added affected-medium severity-blocking enhancement labels Oct 9, 2020 — with ASP.NET Core Issue Ranking

mkArtakMSFT modified the milestones: Next sprint planning, Backlog Oct 9, 2020

mkArtakMSFT modified the milestones: Next sprint planning, Backlog Aug 10, 2021

javiercn mentioned this issue Nov 5, 2021

Link generation improvements #38121

Open

mkArtakMSFT added the triaged label Oct 12, 2022

mkArtakMSFT modified the milestones: Backlog, .NET 8 Planning Oct 12, 2022

MackinnonBuck added the webui-P3-MB label Nov 8, 2022

TanayParikh added the webui-P3-TP label Nov 9, 2022

SteveSandersonMS added the webui-P3-SS label Nov 10, 2022

javiercn added the webui-P1-JC label Nov 10, 2022

danroth27 added the webui-P2-DR label Nov 11, 2022

mkArtakMSFT added needs-prototype Priority:2 and removed investigate labels Nov 15, 2022

captainsafia removed the Bottom Up Work label May 5, 2023

mkArtakMSFT removed the triaged label Oct 20, 2023

mkArtakMSFT removed webui-P2-DR labels Nov 5, 2023

captainsafia modified the milestones: .NET 8 Planning, Backlog Mar 1, 2024

javiercn removed their assignment Jan 28, 2025

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

MapDynamicControllerRoute doesn't work with DefaultLinkGenerator #16965

MapDynamicControllerRoute doesn't work with DefaultLinkGenerator #16965

ollieferns commented Nov 11, 2019 •

edited

Loading

javiercn commented Nov 11, 2019

oferns commented Nov 13, 2019 •

edited

Loading

oferns commented Nov 15, 2019

ollieferns commented Nov 26, 2019

ollieferns commented Dec 9, 2019

oferns commented Mar 17, 2020

MaxHorstmann commented May 18, 2020

mkArtakMSFT commented May 26, 2020

JeremyCaney commented Aug 17, 2020

ghost commented Oct 9, 2020

enricoe73 commented Jul 5, 2021 •

edited

Loading

ghost commented Aug 10, 2021

oferns commented Aug 10, 2021

thilap-web commented Sep 21, 2021

rjgotten commented Nov 8, 2021 •

edited

Loading

ghost commented Oct 12, 2022

MapDynamicControllerRoute doesn't work with DefaultLinkGenerator #16965

MapDynamicControllerRoute doesn't work with DefaultLinkGenerator #16965

Comments

ollieferns commented Nov 11, 2019 • edited Loading

Describe the bug

To Reproduce

Further technical details

javiercn commented Nov 11, 2019

oferns commented Nov 13, 2019 • edited Loading

oferns commented Nov 15, 2019

ollieferns commented Nov 26, 2019

ollieferns commented Dec 9, 2019

oferns commented Mar 17, 2020

MaxHorstmann commented May 18, 2020

mkArtakMSFT commented May 26, 2020

JeremyCaney commented Aug 17, 2020

ghost commented Oct 9, 2020

enricoe73 commented Jul 5, 2021 • edited Loading

ghost commented Aug 10, 2021

oferns commented Aug 10, 2021

thilap-web commented Sep 21, 2021

rjgotten commented Nov 8, 2021 • edited Loading

ghost commented Oct 12, 2022

ollieferns commented Nov 11, 2019 •

edited

Loading

oferns commented Nov 13, 2019 •

edited

Loading

enricoe73 commented Jul 5, 2021 •

edited

Loading

rjgotten commented Nov 8, 2021 •

edited

Loading