DLL hell for DNN during upgrade process

[donker]

Is there an existing issue for this?

• I have searched the existing issues

Description of problem

With more and more features available through Nuget that drag in .net core libraries, there is a concern about the upgrade process.

DNN's (classic) upgrade process

In the old ways of doing things we (force) copied the contents of a _Upgrade.zip package over everything that is in the existing DNN installation. Then, when restarting the site, the upgrade process will kick off by itself. During the first step we overwrite any old dlls in the bin folder with the new ones from the _Upgrade.zip package.

Why is this problematic?

We now ship with more and more Microsoft .net libraries that are not part of .net Framework. Like Microsoft.Bcl.AsyncInterfaces.dll for instance. But these libraries underly many nuget packages out there. So when a module developer includes a nuget package, it may very well drag in one of these libraries with it.

Now we are approaching classic .net DLL hell. Let's assume the module is correctly packaged and announces these dlls as assemblies. During the module's install, DNN will check whether the dll is newer than the one that shipped with DNN. If so, the new dll is copied into the bin folder and the correct binding redirect is set in the web.config.

As you can see coming, now when you upgrade DNN by copying over that underlying dll from the core distribution your site will break because the binding redirect points to the newer dll which has just been overwritten. This is not recoverable from the UI and one needs to carefully prune all dlls to see which one has been erroneously overwritten.

And ...

As we add more and more "modern" features to DNN, we add more and more of these dlls to our distribution. If we wish to add Serilog, for instance, we will import between 15 and 20 dlls from .net. It is already a tedious process to debug a couple of dll breakages. Adding 15 .net dlls risks making DNN "unupgradable".

Description of solution

The solution is to use an installer for DNN. Since version 10.1 we have an internal installer and I (Peter Donker) am working on the UI for this internal installer. The installer takes a DNN install zip from the App_Data/Upgrade folder, FIRST checks all the dlls in that zip and then selective copies them over (same install process as for modules) before copying over the rest.

BUT. For this to really work we need to enforce this method to avoid people breaking their sites. So my proposal is:

• To no longer distribute the _Upgrade.zip packages but instead only the _Install packages.

Anyone familiar with the old way of upgrading will notice the absence of this package and will look for why this is. We will explain the new way of upgrading which would be through the UI.

Description of alternatives considered

No response

Anything else?

No response

Do you plan to contribute code for this enhancement?

• Yes

Would you be interested in sponsoring this enhancement?

• Yes

Code of Conduct

• I agree to follow this project's Code of Conduct

[bdukes]

I agree that we must find a way to drive people to use the new built-in upgrade functionality so that DNN doesn't get stuck unable to upgrade assemblies. I think this solution makes sense, we'll just need a plan for communicating this change well in a number of avenues (release notes, docs, blogs, etc.). Thanks for working hard to make this happen!

[jeremy-farrance]

Would the installer be able to handle complicated situations? The recent one with Microsoft.Bcl.AsyncInterfaces.dll (and in the past the Newtonsoft DLL) on DNN upgrade OR install of a module could overwrite the dll with a new or OLDER version. Fixing the situation with the older dll required restoring the newer dll and then adding a binding redirect (and a brief compatibility prayer [smirk]).

Will the installer be able to handle these situations? Keep the newer DLL (seems likely) and create a binding redirect that maps both versions to the newer DLL?

OR, am I not seeing a bigger picture and these situations end up eliminated either by the new installer or something else outside my awareness?

[bdukes]

The installer is using the exact same process that would be used if a module was installed which had a dependency on that assembly. In general, a newer assembly will be used and a binding redirect will be added or updated.

[mitchelsellers]

@jeremy-farrance Essentially, yes, it should all be fixed with this new process. I've tested and the specific one you noted isn't an issue with the new way!