-
Notifications
You must be signed in to change notification settings - Fork 10.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Url.RouteUrl is blank in ASP.NET Core 3.0 #14877
Comments
@shapeh Thanks for contacting us. In order for us to investigate this issue, could you please provide a link to a github repo with a minimal repro project and detailed steps to reproduce the issue? |
@javiercn Thanks for getting back so quickly. It is impossible for me to do a github repo given the size of the project + confidentiality.
And this is the
|
@shapeh we are not looking for the whole app, rather a minimalistic repro - trimmed down to only the changes on top of a new project template, which demonstrates the issue. |
@mkArtakMSFT Got it / will see what I can do and revert :) |
@shapeh we're closing this issue as we haven't heard back from you for some time now. Feel free to comment/reopen this issue when you have a repro available. |
Sorry about the late response - this is still open / I need just to free up an hour to do the repro. |
I'm experiencing this issue as well in cloudscribe SimpleContent. I'm using named routes that expect a culture route constraint:
but when I'm on a page like /fr/about which is the view url for a cms page, the culture parameter from the current url is not picked up when generating a link to the edit page like this:
the model.EditPath ends up as null, whereas before 3.0 it would have been /fr/editpage/about |
@joeaudette can you please provide a minimalistic repro (ideally GitHub hosted) so we can investigate this further? |
@mkArtakMSFT cloudscribe is a pretty complex setup with route constraints for folder multi-tenancy and culture, I'm not sure I can create a small repro of the issue. Endpoint routing was a major rewrite of the routing system so this is surely a bug. I hope you can investigate it on your end based on the description of the problem and not close the issue if I don't make a small repro for you. For now I'm going to have to disable endpoint routing and go back to traditional mvc routing as a workaround, maybe I'll try endpoint routing again after you guys ship the next version or patch. |
Talked to @rynowak regarding this and this is and this is one of the differences Endpoint Routing has in comparison to routing in 2.2. Specifically, Endpoint routing doesn't preserve ambient values when generating links to other actions. We'll look into solving this somehow during 5.0. |
My observation is that it does preserve my culture route parameter and constraint when using Url.Action(...), but it does not with Url.RouteUrl(...) |
Just to keep this alive and ensure it's known that this is an issue for more than one group of people, we hit this issue today as we attempted to migrate to dotnet core 3.0 and found that the implicit routing didn't work as we expected it to from 2.2. You can see a quick sample we created to see if there were any simple workarounds from having to write out many properties manually for our redirects and internal routing pieces: https://github.com/accu-jmellottlillie/WebRoutingBug |
I have the same issue - see my report to Microsoft: #17097 I have researched the issue more and found that this is the result of change of algorithm that is used for url generation. The old algorithm did sometimes generate incorrect url so Microsoft changed the algorithm. They use something they call ambient Values for generating URL You can read about the algoritm here: https://docs.microsoft.com/en-us/aspnet/core/fundamentals/routing?view=aspnetcore-3.0#url-generation-reference One solution if its possible, is to manually inject Ambient value for culture into the pipeline. I asked Microsoft if that was possible a couple of days ago, but haven't got any answer. |
It's a bit strange that this does work: This doesn't work: We could theoretically create a loop and insert one Route for each culture, but this doesn't feel like a good design pattern. |
|
Just thought I'd weigh in here too as someone who has come across a related issue with routing differences between 2.2 and 3.0. I believe the root cause is the same as this issue is describing. To cut a long story short, RedirectToAction on 3.0 doesn't seem to resolve the URL if the action that it's redirecting to depends on a shared controller-level parameter. E.g. take this controller as an example:
In 2.2, if you navigate to the controller at Here's a small sample with two web apps, one on 2.2 and one on 3.0 which repros the issue: https://github.com/jtb637/RoutingIssue |
Figured I'd add that we ran into this issue when upgrading from 2.2 to 3.1. UrlHelper.RouteUrl, when called with a named attribute route, did not apply ambient values correctly, so a call to This was not consistent; some URLs worked, and some didn't, and we couldn't find why some worked. But specifying ambient values worked. |
As stated earlier, this is a problem with ambient values not being passed on unless specified explicitly like so:
For us, this is a major problem as we have 500+ URLs generated with either Url.RouteUrl or link. Decorating every single link with ambient values seems the wrong design pattern. Someone here https://stackoverflow.com/questions/59267971/using-routedatarequestcultureprovider-in-asp-net-core-3-1 created a new taghelper to solve the problem but, this means customization again. |
Any update on this? I am on core 3.1 and neither Url.Page nor Url.RouteUrl is working. |
* Implement validators using Fluent Validation * Setup Dependency Injection * Implement custom logic to return location of created resource. Due to a bug with URLHelper implementation (dotnet/aspnetcore#14877) i am not able to use URLHelper.ActionLink api to return the link of the created resource. As of now it's not 100% validated that the above mentioned issue is the reason. But for now i haven't investigated much, but made sure this work is done in a robust manner to best of the knowledge. This needs refactoring in the future. * Implement Persistence (In-Memory) using EF Core. * The project file `Hahn.ApplicationProces.May2020.Tests.csproj` is modified to include the SDK `<Project Sdk="Microsoft.NET.Sdk.Web">` to enable integration testing. * Include coverlet.msbuild package to support code coverage * Create a test factory that can supply objects for both unit and integration testing * Add integration tests for Controller * Add unit tests for service and validator * Implement Equals method in `applicant.cs` to support equality comparison by properties. This is primarily used in unit testing. For now the hash code implemention is not robust but we don't have any use case to make it stronger. * Passing the options parameter to every call to ApplicantContext is not intutive. So made the options as static and passed it implicitly to the base class DbContext, while the ApplicantContext continues to be parameterless. new file: Hahn.ApplicationProces.May2020.Web.Tests/Controller/ApplicationControllerIntegrationTests.cs deleted: Hahn.ApplicationProces.May2020.Web.Tests/Controller/ApplicationControllerTests.cs new file: Hahn.ApplicationProces.May2020.Web.Tests/Domain/ApplicantServiceTests.cs new file: Hahn.ApplicationProces.May2020.Web.Tests/Domain/ValidatorTests.cs modified: Hahn.ApplicationProces.May2020.Web.Tests/Hahn.ApplicationProces.May2020.Tests.csproj new file: Hahn.ApplicationProces.May2020.Web.Tests/Properties/launchSettings.json deleted: Hahn.ApplicationProces.May2020.Web.Tests/Service/ApplicantControllerTests.cs new file: Hahn.ApplicationProces.May2020.Web.Tests/TestObjectFactory.cs new file: Hahn.ApplicationProces.May2020.Web.Tests/TestResults.info modified: Hahn.ApplicatonProcess.May2020.Data/Applicant.cs modified: Hahn.ApplicatonProcess.May2020.Data/ApplicantContext.cs new file: Hahn.ApplicatonProcess.May2020.Data/ApplicantRepository.cs modified: Hahn.ApplicatonProcess.May2020.Data/Hahn.ApplicatonProcess.May2020.Data.csproj new file: Hahn.ApplicatonProcess.May2020.Data/IApplicantRepository.cs new file: Hahn.ApplicatonProcess.May2020.Domain/ApplicantAlreadyExistsException.cs new file: Hahn.ApplicatonProcess.May2020.Domain/ApplicantMissingExcpetion.cs modified: Hahn.ApplicatonProcess.May2020.Domain/ApplicantService.cs new file: Hahn.ApplicatonProcess.May2020.Domain/ApplicantValidator.cs modified: Hahn.ApplicatonProcess.May2020.Domain/Hahn.ApplicatonProcess.May2020.Domain.csproj modified: Hahn.ApplicatonProcess.May2020.Domain/IApplicantService.cs new file: Hahn.ApplicatonProcess.May2020.Domain/IApplicantValidator.cs new file: Hahn.ApplicatonProcess.May2020.Domain/ValidationFailedException.cs deleted: Hahn.ApplicatonProcess.May2020.Web/Applicant.cs modified: Hahn.ApplicatonProcess.May2020.Web/Controllers/ApplicantController.cs modified: Hahn.ApplicatonProcess.May2020.Web/Hahn.ApplicatonProcess.May2020.Web.csproj modified: Hahn.ApplicatonProcess.May2020.Web/Startup.cs
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 have also run into this issue upgrading to 3.1. We were using the ambient route values in a multi tenant app's admin screen where the tenants config was managed. We have created a tag helper that injects the currently managed tenant id and a custom UrlHelper extension. For this you can access current route values and append them to an action quite easily:
|
I noticed that the issue also exists in my API project, when a controller doesn't have a default, [HttpGet] public string Ping() => "Pong"; |
…he URL generation
Thanks for contacting us. We're moving this issue to the |
Describe the bug
We are upgrading an ASP.NET Core 2.2. MVC app to 3.0 but Url.RouteUrl gives blank href's and inconsistency on link creation. What are we doing wrong?
To Reproduce
Steps to reproduce the behavior:
Example 1 -wrong result
Returns https://example.org/us/blog/some-title-6 in 2.2 but is blank in 3.0:
We have tried these constructions but result is not satisfactory:
// Returns https://example.org/us/blog/details/6?title=some-title
Startup.cs
Example 2 - wrong result
Returns https://example.org/us/home/pricing instead of
https://example.org/us/pricing
Example 3 - correct result
Returns correct https://example.org/us/signup/customer
Additional context
dotnet --info
.NET Core SDK (reflecting any global.json):
Version: 3.0.100
Commit: 04339c3a26
Runtime Environment:
OS Name: Windows
OS Version: 10.0.18362
OS Platform: Windows
RID: win10-x64
Base Path: C:\Program Files\dotnet\sdk\3.0.100\
Host (useful for support):
Version: 3.0.0
Commit: 7d57652f33
.NET Core SDKs installed:
2.1.202 [C:\Program Files\dotnet\sdk]
2.1.502 [C:\Program Files\dotnet\sdk]
2.1.504 [C:\Program Files\dotnet\sdk]
2.1.505 [C:\Program Files\dotnet\sdk]
2.1.507 [C:\Program Files\dotnet\sdk]
2.1.602 [C:\Program Files\dotnet\sdk]
2.1.604 [C:\Program Files\dotnet\sdk]
2.1.700 [C:\Program Files\dotnet\sdk]
2.1.801 [C:\Program Files\dotnet\sdk]
2.1.802 [C:\Program Files\dotnet\sdk]
2.2.100 [C:\Program Files\dotnet\sdk]
2.2.102 [C:\Program Files\dotnet\sdk]
2.2.104 [C:\Program Files\dotnet\sdk]
2.2.105 [C:\Program Files\dotnet\sdk]
2.2.203 [C:\Program Files\dotnet\sdk]
2.2.301 [C:\Program Files\dotnet\sdk]
3.0.100 [C:\Program Files\dotnet\sdk]
.NET Core runtimes installed:
Microsoft.AspNetCore.All 2.1.0 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
Microsoft.AspNetCore.All 2.1.1 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
Microsoft.AspNetCore.All 2.1.2 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
Microsoft.AspNetCore.All 2.1.5 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
Microsoft.AspNetCore.All 2.1.6 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
Microsoft.AspNetCore.All 2.1.8 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
Microsoft.AspNetCore.All 2.1.9 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
Microsoft.AspNetCore.All 2.1.11 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
Microsoft.AspNetCore.All 2.1.12 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
Microsoft.AspNetCore.All 2.1.13 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
Microsoft.AspNetCore.All 2.2.0 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
Microsoft.AspNetCore.All 2.2.1 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
Microsoft.AspNetCore.All 2.2.2 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
Microsoft.AspNetCore.All 2.2.3 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
Microsoft.AspNetCore.All 2.2.4 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
Microsoft.AspNetCore.All 2.2.6 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
Microsoft.AspNetCore.App 2.1.0 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 2.1.1 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 2.1.2 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 2.1.5 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 2.1.6 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 2.1.8 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 2.1.9 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 2.1.11 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 2.1.12 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 2.1.13 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 2.2.0 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 2.2.1 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 2.2.2 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 2.2.3 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 2.2.4 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 2.2.6 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 3.0.0 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.NETCore.App 2.0.9 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 2.1.5 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 2.1.6 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 2.1.8 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 2.1.9 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 2.1.11 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 2.1.12 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 2.1.13 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 2.2.0 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 2.2.1 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 2.2.2 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 2.2.3 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 2.2.4 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 2.2.6 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 3.0.0 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.WindowsDesktop.App 3.0.0 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Ref #12794
The text was updated successfully, but these errors were encountered: