When using a custom URL provider in 7.3+ I get a compiler message that DefaultUrlProvider.DefaultUrlProvider() constructor is obsolete. It tells me also to add the constructor with the IRequestHandlerSection parameter.
So, I have added the constructor as below:
public MyUrlProvider(IRequestHandlerSection requestSettings)
: base(requestSettings)
{ }
But after doing this my method "GetUrl" is never called again.
public override string GetUrl(UmbracoContext umbracoContext, int id, Uri current, UrlProviderMode mode)
{
// never called again after adding the constructor
}
I am pretty sure I am missing something. Can someone help me out?
Can someone explain if Damiaan has the correct fix?
All this is doing is implementing the backward compatibility fix from the core. Which is basically exactly the same as calling the deprocated constructor.
Is there a preferred way to initiate the constructor. I imagine the core code does this with a resolver UrlProviderResolver which is why using UmbracoConfig is now deprecated?
Basically my question is : Is there a nice way to use UrlProviderResolver and register a custom class which extends DefaultUrlProvider without hard coding the config?
Core "resolves" the IUrlProvider instances ie it calls their parameter-less constructors. So the parameter-less ctor is still used by Core. However, we have an ultimate goal (v8) of moving to proper dependency injections. The new ctor would be used and the config section would be provided by the injection container.
At the moment we are in-between: the new ctor is here, the old one is obsolete, but you still have to use it. Sorry for the confusion ;-)
Surely the parameter less constructor shouldn't be marked as obsolete as yet though?
Adding a workaround by duplicating core code means future nuget upgrades will not mark my code with an obsolete warning as I have just implemented the none obsolete constructor in an obsolete way!
I understand adding in code ready for the IOC in V8 but think old methods should be marked obsolete when v8 is released and not now.
I've used the new constructor (as defined by Damiaan) and it looks like GetUrl() is never called, so I think Stephen means we still have to use the old one despite the warning (please correct me if I'm wrong)
override defaultUrlProvider not working when new constructor is used
Hi
When using a custom URL provider in 7.3+ I get a compiler message that DefaultUrlProvider.DefaultUrlProvider() constructor is obsolete. It tells me also to add the constructor with the IRequestHandlerSection parameter.
So, I have added the constructor as below:
But after doing this my method "GetUrl" is never called again.
I am pretty sure I am missing something. Can someone help me out?
Found it!
when inheriting from the
DefaultUrlProviderHad the same problem - thanks for sharing!
Just having a similar issue.
Can someone explain if Damiaan has the correct fix?
All this is doing is implementing the backward compatibility fix from the core. Which is basically exactly the same as calling the deprocated constructor.
Is there a preferred way to initiate the constructor. I imagine the core code does this with a resolver UrlProviderResolver which is why using UmbracoConfig is now deprecated?
Basically my question is : Is there a nice way to use UrlProviderResolver and register a custom class which extends DefaultUrlProvider without hard coding the config?
Thanks
What Damian says.
Core "resolves" the IUrlProvider instances ie it calls their parameter-less constructors. So the parameter-less ctor is still used by Core. However, we have an ultimate goal (v8) of moving to proper dependency injections. The new ctor would be used and the config section would be provided by the injection container.
At the moment we are in-between: the new ctor is here, the old one is obsolete, but you still have to use it. Sorry for the confusion ;-)
Thanks for clearing up Stephen.
Surely the parameter less constructor shouldn't be marked as obsolete as yet though?
Adding a workaround by duplicating core code means future nuget upgrades will not mark my code with an obsolete warning as I have just implemented the none obsolete constructor in an obsolete way!
I understand adding in code ready for the IOC in V8 but think old methods should be marked obsolete when v8 is released and not now.
Thanks
Carl
Stephen, when you say "you still have to use it", is 'it' the old or new constructor?
I have code:
Is it OK, or do I need to change it to:
I've used the new constructor (as defined by Damiaan) and it looks like GetUrl() is never called, so I think Stephen means we still have to use the old one despite the warning (please correct me if I'm wrong)
is working on a reply...