IUrlHelper depends on ActionContext obsoleted in ASP.NET Core 10

[timstokman]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

For asp .net core 9 and lower, you could inject the url helper like this:

services.AddScoped<IUrlHelper>(x =>
{
   var actionContext = x.GetRequiredService<IActionContextAccessor>().ActionContext;
   var factory = x.GetRequiredService<IUrlHelperFactory>();
   return factory.GetUrlHelper(actionContext);
});

ActionContextAccessor is now obsolete, in the future that would probably mean there'd be no way to get an actioncontext (and also no way to get the url helper).

My suggestions would be:

• Make sure you can construct url helpers with the new EndpointMetadataCollection
• Make the url helper available as a scoped service by default in the dependency injection

Expected Behavior

For a service not to depend on obsoleted classes, for there to be a supported way of using IUrlHelper

Steps To Reproduce

The traditional way of instantiating IUrlHelper is now giving warnings, and in the future will be impossible:

services.AddScoped<IUrlHelper>(x =>
{
   var actionContext = x.GetRequiredService<IActionContextAccessor>().ActionContext;
   var factory = x.GetRequiredService<IUrlHelperFactory>();
   return factory.GetUrlHelper(actionContext);
});

Exceptions (if any)

No response

.NET Version

10.0.10

Anything else?

No response

[jcageman]

Ran into the same issue, i switched to using this.Url on the BaseController, since i was only using the urlhelper within controllers

[timstokman]

Ran into the same issue, i switched to using this.Url on the BaseController, since i was only using the urlhelper within controllers

Some of the methods/functionality in the IUrlHelper can be found elsewhere, I'm currently using IsLocalUrl for some security checks in an authentication flow, that one can only be found in IUrlHelper. I could copy or reimplement it, but I'd rather depend on something in ASP.NET core.

[martincostello]

@timstokman Tada: #57363

[timstokman]

Thank you, that should help with my migration, didn't realize it was available there. Solves my use-case at least.

Still, I think it'd be nice if the UrlHelper was easily available through dependency injection, especially since the old method of doing that is now marked obsolete. Makes things a little easier in the business layer.

[failwyn]

I'm running into this same issue as well; I process a lot of data that has "~/" in the relative path which LinkGenerator throws an exception for; I could add string.Replace everywhere we convert from UrlHelper to LinkGenerator, but I'd rather continue using the UrlHelper if it's not going to be marked obsolete next.