Dnn.platform: Method not found: 'System.String DotNetNuke.Services.Url.FriendlyUrl.FriendlyUrlProvider.FriendlyUrl(DotNetNuke.Entities.Tabs.TabInfo, System.String, System.String, DotNetNuke.Entities.Portals.PortalSettings)'

[marietteknap]

Description of bug

9.4.2 has broken all of our modules due to Method not found: 'System.String DotNetNuke.Services.Url.FriendlyUrl.FriendlyUrlProvider.FriendlyUrl(DotNetNuke.Entities.Tabs.TabInfo, System.String, System.String, DotNetNuke.Entities.Portals.PortalSettings)'.

Error log

2019-11-13 10:05:23.285+01:00 [WIN-SVOFJIQAQ17][D:8][T:9][FATAL] DotNetNuke.Framework.PageBase - An error has occurred while loading page.
System.MissingMethodException: Method not found: 'System.String DotNetNuke.Services.Url.FriendlyUrl.FriendlyUrlProvider.FriendlyUrl(DotNetNuke.Entities.Tabs.TabInfo, System.String, System.String, DotNetNuke.Entities.Portals.PortalSettings)'.
at Mandeeps.DNN.Libraries.URL.Factories.URLFactory.GetFriendlyURL(Nullable1 ModuleID, PortalSettings pS, String QueryParameters, URLEntity u) at Mandeeps.DNN.Modules.LiveArticles.Components.LiveArticlesController.GetArticleLink(ArticleVersion article, VersionPage vPage) at Mandeeps.DNN.Modules.LiveArticles.Components.LiveArticlesController.ReplaceArticleTokens(ArticleVersion Article, String Template, Int32 UserId, Dictionary2& RenderControlsDefinition, Boolean ThumbnailReplace, Int32 CurrentPageId, Widget wt, Boolean UseStoredProcedure, Boolean IsAjaxPreview)
at Mandeeps.DNN.Modules.LiveArticles.Components.LiveArticlesController.RenderRecentArticles(Widget widget, Int32 UserId, Dictionary`2& RenderControlsDefinition)
at Mandeeps.DNN.Modules.LiveArticles.UI.LiveArticlesWidget.View.Initialize()
at System.Web.UI.Control.OnLoad(EventArgs e)
at DotNetNuke.Entities.Modules.PortalModuleBase.OnLoad(EventArgs e)
at System.Web.UI.Control.LoadRecursive()
at System.Web.UI.Control.LoadRecursive()
at System.Web.UI.Control.LoadRecursive()
at System.Web.UI.Control.LoadRecursive()
at System.Web.UI.Control.LoadRecursive()
at System.Web.UI.Control.LoadRecursive()
at System.Web.UI.Control.LoadRecursive()
at System.Web.UI.Control.LoadRecursive()
at System.Web.UI.Control.LoadRecursive()
at System.Web.UI.Control.LoadRecursive()
at System.Web.UI.Control.LoadRecursive()
at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)

Additional context

See https://github.com/dnnsoftware/Dnn.Platform/blob/8151da229c803ea82cb7956d3c36bb322d4634ed/DNN%20Platform/Library/Services/Url/FriendlyUrl/FriendlyUrlProvider.cs#L50

Affected version

• [ x ] 9.4.2

Affected browser

• [x] Chrome
• [x] Firefox
• [x] Safari
• [x] Internet Explorer
• [x] Edge

[marietteknap]

A suggested solution is to revert this in 9.4.3?

[valadas]

Ok, so if I understand correctly, in #3160 the overload was modified to use the IPortalSettings abstraction instead of PortalSettings, but from the comments on there, PortalSettings does Inherit from IPortalSettings already and for that reason this was not expected to be a breaking change. It would be really nice to get some testing from module vendors before/during the RC stages to spot these issues before releases.

[meetmandeep]

@valadas Mariette did reported this issue about 24 hours prior to official release of DNN 9.4.2. Our team confirmed the issue and we were still gathering more information regarding the cause; however, official release was rolled out the same day.

Perhaps, we can have designated minimum days after RC before release?

[valadas]

Really? We have been discussing PR #3160 since mid-october including possible breaking changes. The RC has been published on November 5th, the release on November 12th and this issue reported today... Did I miss something?

[meetmandeep]

Perhaps, I'm missing the boat. We don't individually track PR requests or individual issues. We only test our products when RC is released. Considering we have over 60+ products; that's a significant undertaking and takes some resources.

I simply suggested that we should have a defined minimum days prior to release so we're aware that if an RC is released on 1st; it will not be officially released until 7th or 15th. Just a suggestion... I'm not stepping on your toe.

Issue was originally reported by Mariette on Slack. We were working with her and we did point out to her that this is a DNN issue. DNN 9.4.2 was released while we were investigating.

Again, my post here was to suggest to avoid this in future. But if suggestions are not welcome then I'm very sorry.

[valadas]

No, no worries, just trying to figure this out because I did not see that reported before final went out and it was not expected to be a breaking change. That being said it would be nice to have more module vendors follow the progress of the platform and chime in on those types of risks on their end... I think nobody makes breaking changes on purpose and we try to test as much as possible but it has been a couple times that module vendors report issues right after the official release. We had 2-3 weeks RC stages and it happened too...

9.4.0 was in RC stage from July 19th and got out on September 11th and issues with some modules where reported one or two days after the official release... I am not blaming anyone but looking into solutions and I believe the RC period is not the major issue, it is more to get some module vendors to follow on ideas and upcoming changes before they become an issue...

[meetmandeep]

I agree. We can commit to testing for each RC; but we do need a minimum defined RC period. We only had 4 business days between Nov 5th and 12th; it's extremely hard to re-allocate resources to test 60+ products within such a short span.

We can discuss this further in our next Tech Advisory meeting.

[meetmandeep]

but from the comments on there, PortalSettings does Inherit from IPortalSettings already and for that reason this was not expected to be a breaking change.

@valadas My understanding is that the breaking change is caused due to introduction of IPortalSettings in DotNetNuke.Abstractions.dll

[valadas]

we do need a minimum defined RC period

This is what was in the roadmap though https://dnncommunity.org/road-map it only got 1 day later than planned for both the RC and the release...

introduction of IPortalSettings in DotNetNuke.Abstractions.dll

Yes it appears this is the cause, reverting the change might be a big thing, maybe we can find a way to have some sort of alias to it or an additional overload deprecated for a future release or some such...

Mariette did reported this issue about 24 hours prior to official release of DNN 9.4.2

This is the part I did not get, knowing it before the release, for sure would have been a good reason to not publish it yet, but I did not see that issue before the release myself.

[marietteknap]

This was the first version I was involved in testing and the result shows. I am happy with this though more time to correct major issues like the one we see now is really needed. I had a slow start testing because it was the first time, next time will be better and quicker.

[thabaum]

I will try to test these modules on one of my test sites as well to help with these. My beta sites do not have much on it currently because I start them from scratch a lot.

I will load up 2sxc for those users and Mandeeps collections. I can't say I will be there for every RC but I will try to help here as they both seem to have been hit by updates. I can be an extra voice when I can.

[thabaum]

This would be good to put as Known Issues to help stop others now.

[valadas]

Yeah, test early, test often :) Any testing hands are welcome specially regarding upgrades and third party modules.

[marietteknap]

@valadas Can you add this to the release notes please?

[valadas]

Sure can

[valadas]

Done

[thabaum]

Thank you @valadas

[b-creative]

I can confirm also the same errors using Ventrian News Articles.
https://github.com/ventrian/News-Articles/issues/42

[thabaum]

Maybe we can push out a 9.4.3 RC fix soon with the fix and start a 9.4.4 milestone.

I have a PR I would like to see working that is in 9.4.3 and one I will put together today that was my first accepted in 10 but should be in 9 I will redo right now.

[valadas]

We certainly have a better setup now for quick release cycles. Now the thing is how do we resolve this issue? @ahoefling @mitchelsellers opinions? Add an overload marked deprecated for Dnn10? Or do you guys have better ideas to handle this?

[thabaum]

I can confirm also the same errors using Ventrian News Articles.
ventrian/News-Articles#42

I will add this module as well.

Thanks @b-creative @marietteknap for stepping up here with testing efforts for the community... YOUR AWESOME!

[bdukes]

I'm working on a PR that will add back the overloads but mark them as deprecated. Still testing that it fixes the issue and doesn't cause compilation issues going forward (e.g. ambiguous overload)

[valadas]

Merged, will be out with 9.4.3 soon...