Server errors when updating DNN from 9.10.1 to 9.10.2 after 2sxc upgrade to v13

[enfJoao]

I'm submitting a ...
[x] bug report

...about
[x] DNN parts
[x] other / unknown

Current behavior
I upgraded 2sxc to v13 a couple days ago. No issues.
I tried to upgrade DNN from 9.10.1 to 9.10.2 and I get these errors:
Could not load file or assembly 'Microsoft.Extensions.DependencyInjection.Abstractions' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)

My web.config:

<dependentAssembly xmlns="urn:schemas-microsoft-com:asm.v1">
    <assemblyIdentity name="Microsoft.Extensions.DependencyInjection.Abstractions" publicKeyToken="adb9793829ddae60" />
    <bindingRedirect oldVersion="0.0.0._0-32767.32767.32767.32767" newVersion="2.2.0.0" />
</dependentAssembly>

See Fix Here: #2684

[enfJoao]

My files in bin\2sxc read version 1.1.1
The one in bin version 2.1.1

[Edit]
After manually fixing the version of the files in webconfig, I got this site to work, but I don't know if this will have long run consequences. Even mailkit and Mimekit were affected.

[Edit]
I get it. 2sxc installs newer version of the files and updates web.config. DNN upgrade replaces those files with older versions but does not change the config. Nasty.

[iJungleboy]

Yes, that's the problem.

And it's related to how Dnn doesn't keep track of it's own dependencies - so it never checks them on an upgrade. All other modules do.

As of now, I don't see that we can fix this, Dnn should do something. So please open an issue there.

[jeremy-farrance]

Daniel, I am hoping you will reconsider this. Dnn is a compiled project with dependencies. One of those is Microsoft DependencyInjection and has been at v2.1.1 for quite a while now. Its a key, core dependency and I believe its even used by the installer. So 2sxc overwriting that DLL and adding a binding redirect that creates this situation is clearly a problem: will cause all future upgrades of Dnn Platform (after the install of 2sxc 13.03) to fail.

You suggested, "Dnn doesn't keep track of it's own dependencies - so it never checks them on an upgrade" - given that you know this, it seems like the responsibility is on you to keep your module compatible and not create a situation that will definitely result in Dnn unable to startup the very next time its upgraded.

Note that I am at best a power-user and a learn-as-you-go developer, not a high level full-time programmer. So please forgive any ignorance in my questions...

Does your module need features in MS DI 2.2.x that are not available in 2.1.1?

• If no, can you adjust your MS DI usage to use v2.1.1?
• If yes, can you go back to putting the MS DI 2.2.x DLL in your own folder (/bin/2sxc/) and doing a custom binding redirect for your needs (similar to what you did for years using MS DI 1.x)?

Are you able or willing to contribute to Dnn Platform:

• the work needed to upgrade Dnn's dependency tracking and upgrading?
• revisions necessary to upgrade Dnn's usage of MS DI 2.1.1 to 2.2.x? (this seems like an opportunity?)

The Dnn Platform community has a lot of diverse members with widely varying skillsets. Is it possible there may be other solutions that could come about via an open discussion? Are you willing to work with Dnn Platform (the community or maybe somehow directly with the Technology group) to either improve the situation or find a solution or workaround?

In closing, 2sxc is a module being installed in to Dnn Platform. I very humbly want you to realize, your comment above ("As of now..."), to me, comes across as frighteningly dismissive. Even if you don't (yet) know of a possible solution, please at least re-open this issue (its closed as I write this) and continue to discuss and hear suggestions, and answer questions.

[david-poindexter]

Thank you @jeremy-farrance for voicing some of what I was thinking. It seems this could have all been avoided by a simple conversation upfront. I am pretty confident no DNN Platform "approver" would object to bumping the DI version as long as it is not a breaking change.

[iJungleboy]

@jeremy-farrance & @david-poindexter - I agree that we should reopen this

My answer above explain the situation as is. It's not a description of what we intended. I myself am frustrated by the status quo.

When we used a newer DI version, we were ourselves not aware of this problem popping up. To be honest, I don't know exactly why we used a slightly newer version,

My guess is that it was either because of Entity Framework - but it could also be a coincidence, as we didn't expect follow-up problems. It could also be that we used the newest one which is compatible with what DNN does, and simply didn't consider that DNN would replace these again.

I believe we should review the options, but that's difficult for many reasons

1. DI in Dnn is not really well done yet - from what I see, it could also be using DI 6.0 as that's .net standard 2 compatible, but the choice to use 2.x when it was introduced (at that time v3 was already viable) indicates choices that were maybe made intentionally, and maybe not.
2. That DNN also doesn't keep track of its own dependencies makes life very difficult
3. The Dnn installer is very limited in what is possible - so many checks which would result in if-this-then-that are simply not possible

Next steps

• @tvatavuk could you briefly check why we used a slightly newer version of the DI?
• Then we should decide if we fix Dnn or 2sxc - but to be honest we probably have to fix 2sxc, because changes in DNN always have to consider so much that happens in other solutions, that it's really hard to do
• Fix

[iJungleboy]

Created instructions how to fix until we have a solution: #2684

[jeremy-farrance]

Thank you for the response above!

I don't have details or a link, but I am aware that at least 1 effort is already underway to update Dnn Platform to use the 2.2x version of MS DI. I don't know whether that will be successful (seems likely) or when that might make it in to a release (weeks?).

[iJungleboy]

According to @tvatavuk the reason is because the ImageFlow resizer needs this as a minimum version. 2sxc wouldn't need this. We'll try to find a workaround.

[david-poindexter]

Thank you @iJungleboy - let me know if I can be of any help in bridging any gaps with DNN Platform. Like @jeremy-farrance mentioned, I know of a community member that was looking into a potential PR to DNN Platform to bump the version of DI in DNN to 2.2.0. Hopefully, that will help.

[iJungleboy]

For now we have an interim solution #2685

Basically only the Image Resizer needs this (or newer) version, so we moved it to "ImageFlow" and added a redirect which is only relevant for exactly this version. Should be released tonight or tomorrow.

thx to @tvatavuk