LinkGenerator generate wrong links across areas (2)

[valeriob]

Hi,
i've just tested the scenario described in this old issue on dotnet 5.0 but it still not working.
#20489
I guess that that feature was not included in the 5.0 planning and unfortunately it's blocking the upgrade of a lot of software due to the regression occurred when switching to the new Routing mechanism in dotnetcore 3.0.
What is the solution to allow ambient parameter to flow between areas for dotnet 5.0 and 6.0 ?

Thanks

[ghost]

Thanks for contacting us.
We're moving this issue to the Next sprint 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.

[valeriob]

Thanks for adding to the next sprint planning. I'll add some info for the use case.
Having global ambient parameter is very useful for many scenario :

1. multitenancy
2. language context
3. other app specifics context related (like displaymode)
4. reimplementing the DisplayMode functionality removed in aspnetcore

It allow to write very clean code, and having a framework that behave like so, roundtripping those values across the whole application.
Without this feature we need to litter everywhere we need to generate a link by adding those ambient values "good luck catching all of them in a big application", or having devs using the wrong mechanism to obtain a similar result (cookies, state somwhere else, etc..).
Can you at least provide an api to configure routing to allow an ambient value to flow across areas ?

Anyway i'm available to help in this feature, even though this code does not really make sense to me, it looks like just an ovverride of a value, not a reason to invalidate the whole ambient value copying process. If indeed we remove that check it works correctly :

[ajbeaven]

I'm also hitting this using culture/language route patterns /{culture}/{area}/{controller}/{action}/{id?}. When switching between areas, ambient route values are ignored (culture in this case). They are ignored even when the route values appear to the left of the area, which is at odds with the docs that describe how route value invalidation should work.

Are there any workarounds for this? This is also stopping us migrating to .NET Core 3.0+.

[valeriob]

Hi,
aspnet core 6 preview 4 just shipped, congratulations ! Can you guys pls do not let this issue slip out of dotnet6 ? I understand the need to innovate on blazor and such, but MVC features like this are very important for ppl to use the framework, it's the very reason to use it in the first place.

[valeriob]

Hello there :D
Gentle reminder that this stuff is really important, i do not see any movement approaching preview 6 and 7, i'm starting to worry.
Thanks

[Muchiachio]

Would be nice to have this fixed for 6.0 as it's been broken for a while now.
@valeriob, what I did was create a decorator for the current LinkGenerator implementation, which adds known "left" ambient values as real route values before link generation. It's ugly and doesn't scale, but it does the job until it gets fixed.

[valeriob]

Thanks @Muchiachio would you be so kind to share an example ?

[Muchiachio]

You can check this commit.

[valeriob]

Hi,
@davidfowl commented on a community standup that the work on RC1 has started, can we get some feedback pretty pls ?
Up to dotnet 2.2 we could opt for the old routing system and it worked, since aspnetcore 3 it's not working anymore (even with EnableEndpointRouting = false) leaving ppl without any options to upgrade. #20489 , the feature was promised for net5, we could wait, but now if it slips net6 it will not be present in any LTS solution for many years !
Can you pls share some insight and a suitable workaround from the product team would be appriciated

[fschmied]

@danroth27 Until now, there hasn't been any feedback from the team on this issue (only by means of labels). Is there any feedback from the ASP.NET Core team on the topic of these "global" ambient values, which could be used up to 2.1 for multinenancy, active culture, etc.?

Related/similar older issues:
#31602 (ambient value for culture not working)
#19927 (ambient value for tenant not working)
#11635 (by design: userId not transferred)
#12794 (by design: slug not transferred)

(Moved from #31602 (comment).)

[danroth27]

@fschmied It's still work we want to do. We just haven't gotten to it yet in our backlog queue. At this point it doesn't look like it's going to make it in for .NET 6 unfortunately.

[valeriob]

Hi @danroth27 that's very unfortunate, it will block ppl from migrating big complex applications from 2.1, we early adopted the framework and than we got stuck due to this issue :(
Can you guys pls at leasts suggest a practial work around for the time being ?
@Muchiachio solution
https://gitlab.com/NonFactors/AspNetCore.Template/-/commit/dba59359d3032e6d72caaca9e05b178d79b26422#51e8e755c2f275c843b1c768a001c40681b37ea0 works, but there is a nasty side effect to double instantiate the container, can you at least give us the option to replace the LinkGenerator class correctly waiting for the proper feature on dotnet 7 ?
Thanks

[fschmied]

@danroth27 Thanks for the info!

(If you have a better workaround than the LinkGenerator decorator, I'd be interested in it, too.)

[ghost]

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.

[tapizquent]

Any updates on this? Seems that multitenancy is not supported due to the AmbientValues being ignored, more specifically the tenant ambient value. This is a very important feature

[danroth27]

@tapizquent This didn't make it into .NET 6, but we are considering this issue for .NET 7.

[valeriob]

Yes, i can't wait to remove that ugly workaround !

[ghost]

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.

[valeriob]

Ouch :( This area of problem shifted from Net5, Net6, Net7 not net8... the hopes to see it addressed are not very high.
All the investment in blazor is really starting to hurt the MVC framework to be honest.

[ghost]

Thanks for contacting us.

We're moving this issue to the .NET 9 Planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. 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.

[valeriob]

I really hope .net 9 is about mvc and less about blazor, i'm starting to worry about the future of the platform... i can't really understand how can you postpone fundamental flaws of a product for so long, dotnet core 3 is 2019.

[danroth27]

I really hope .net 9 is about mvc and less about blazor, i'm starting to worry about the future of the platform... i can't really understand how can you postpone fundamental flaws of a product for so long, dotnet core 3 is 2019.

Hi @valeriob. We will certainly consider MVC issues as part of our .NET 9 planning. Please note though that we have limited resources, so we have to prioritize which issues to focus on. We follow a triage process to determine which issues in our backlog to prioritize. If there are issues that are important to you, please be sure to put a 👍 reaction on the original post and comment about why the issue is important to you. Or if you'd like to contribute a fix to accelerate getting an issue addressed that's also an option.

[konak]

I'm facing the same issue

[arnileibovits]

You can check this commit.

Thank you for the contribution!

There's a more optimal way of registering the custom implementation, without having to build the service provider:

var defaultLinkGeneratorDescriptor = services.First(descriptor => descriptor.ServiceType == typeof(LinkGenerator));
services.AddKeyedSingleton(typeof(LinkGenerator), "DefaultLinkGenerator", defaultLinkGeneratorDescriptor.ImplementationType!);
services.Remove(defaultLinkGeneratorDescriptor);
services.AddSingleton<LinkGenerator>(serviceProvider =>
{
    var defaultImplementation = serviceProvider.GetRequiredKeyedService<LinkGenerator>("DefaultLinkGenerator");
    return new CustomLinkGenerator(defaultImplementation);
});