[Bug]: DNN 10.4.0 RC2 clean install does not protect newer assemblies during 2sxc installation #7518

Is there an existing issue for this?

• I have searched the existing issues

What happened?

This is a continuation of #7510. That issue was addressed by PR #7512, but the same problem is still reproducible with a clean DNN 10.4.0 RC2 installation.

First, many thanks to @donker and the DNN TAG team for the exciting new installation and upgrade process.

This is a significant improvement toward eliminating one of the most frustrating types of DNN installation and upgrade failures: an extension package overwriting newer assemblies already installed by DNN and leaving the website unable to start.

Unfortunately, the problem reported in #7510 still occurs with:

• Clean installation of DNN Platform 10.4.0 RC2
• Clean installation of 2sxc 22.00.00 through the DNN Extensions UI

The 2sxc installation completes without visible errors, and its installation log appears successful. However, after reloading the website, DNN can no longer start and displays:

Could not load type 'Microsoft.Extensions.Logging.ILoggingBuilder'
from assembly 'Microsoft.Extensions.Logging.Abstractions,
Version=2.2.0.0, Culture=neutral,
PublicKeyToken=adb9793829ddae60'.

Comparing the DNN bin directory before and after installing 2sxc shows that several assemblies supplied by DNN 10.4.0 RC2 were replaced by older versions from the extension package. Corresponding binding redirects were also changed to the older deployed versions.

The RC2 protection added by PR #7512 does not appear to run through the step-based clean-install path, so the DNN assemblies are not registered early enough to protect them during subsequent extension installations.

Steps to reproduce?

1. Perform a clean installation using DNN_Platform_10.4.0-rc.2_Install.zip.
2. Confirm that the new DNN website starts and operates normally.
3. Open the DNN Extensions UI.
4. Install ToSic.Sxc.Dnn.22.00.00_Install.zip.
5. Observe that the extension installation completes without reporting an error.
6. Reload the website.
7. Observe that DNN fails during startup with the ILoggingBuilder type-load exception.
8. Compare the bin directory and web.config before and after installing 2sxc.

Current Behavior

The extension installer replaces newer DNN assemblies with older copies from the extension package.

The following assembly-version changes were observed:

This leaves DNN with an incompatible mixture of assemblies and prevents the application from starting.

Expected Behavior

Before installing any extension package, DNN should ensure that the assemblies already present in its bin directory are registered in the Assemblies database table with their current versions.

The extension installer should then:

• Preserve a newer assembly already supplied by DNN.
• Prevent an extension package from replacing it with an older version.
• Preserve or generate binding redirects compatible with the retained assembly.
• Complete the extension installation without leaving DNN in an unusable state.

Relevant log output

System.TypeLoadException: Could not load type
'Microsoft.Extensions.Logging.ILoggingBuilder' from assembly
'Microsoft.Extensions.Logging.Abstractions, Version=2.2.0.0,
Culture=neutral, PublicKeyToken=adb9793829ddae60'.

Anything else?

Info

PR #7512 added Upgrade.EnsureAssembliesRegistered() calls to the legacy Upgrade.InstallDNN and Upgrade.UpgradeDNN paths.

However, the new installation and upgrade wizards install extension packages through:

DotNetNuke.Services.Upgrade.InternalController.Steps.InstallExtensionsStep

In the DNN 10.4.0 RC2 source, InstallExtensionsStep.Execute() starts by calling Upgrade.GetInstallPackages() and then Upgrade.InstallPackage(). It does not call EnsureAssembliesRegistered().

Both the new InstallWizard and UpgradeWizard use this step.

Consequently, a clean installation can finish without registering the assemblies already present in bin. When 2sxc is installed later through the Extensions UI, the installer does not have the registered DNN assembly versions needed to prevent the downgrade.

Suggestion

Register the existing bin assemblies at the beginning of the step-based extension installation:

public override void Execute()
{
    Upgrade.EnsureAssembliesRegistered();

    var packages = Upgrade.GetInstallPackages();
    // Existing implementation...
}

The possible implementation can:

1. Make the existing Upgrade.EnsureAssembliesRegistered() method accessible internally.
2. Call it at the beginning of InstallExtensionsStep.Execute(), before discovering or installing extension packages.

Affected Versions

develop build (unreleased)

What browsers are you seeing the problem on?

No response

Code of Conduct

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