Empty namespace xmlns="" added to several dependentAssembly nodes in web.config during DNN upgrade

Description of bug

Module installed on upgraded DNN 9.4.0 RC1 can stop working with exception like this:

Could not load file or assembly 'System.Web.Http.WebHost, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)

Steps to reproduce

List the steps to reproduce the behavior:

Clean DNN install scenario

1. Clean install DNN 9.4.0 RC1 using DNN_Platform_9.4.0-rc1.20742_Install.zip.
2. Install module that depend on eg. System.Web.Http.WebHost.
   1. Here is 2sxc install package that works on DNN 7.4.2 - 9.4.0 RC1 2sic_2SexyContent_09.43.02_dnn940comp_Install.zip
3. And module to page. Module is working.

Upgrade DNN scenario

1. Clean install DNN 7.4.2.
2. Upgrade to DNN 9.4.0 RC1 using DNN_Platform_9.4.0-rc1.20742_Upgrade.zip.
3. Install module that depend on eg. System.Web.Http.WebHost.
   1. Here is 2sxc install package that works on DNN 7.4.2 - 9.4.0 RC1 2sic_2SexyContent_09.43.02_dnn940comp_Install.zip
4. And module to page. Module is not working. We get exception:

Could not load file or assembly 'System.Web.Http.WebHost, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)

Current result

In upgraded web.config, several nodes for dependent assemblies have namespace attribute empty xmlns="".

      <dependentAssembly xmlns="">
        <assemblyIdentity name="System.Web.Http" publicKeyToken="31BF3856AD364E35" />
        <bindingRedirect oldVersion="0.0.0.0-5.2.3.0" newVersion="5.2.3.0" />
      </dependentAssembly>
      <dependentAssembly xmlns="">
        <assemblyIdentity name="System.Net.Http.Formatting" publicKeyToken="31bf3856ad364e35" />
        <bindingRedirect oldVersion="0.0.0.0-5.2.3.0" newVersion="5.2.3.0" />
      </dependentAssembly>
      <dependentAssembly xmlns="">
        <assemblyIdentity name="System.Web.Http.WebHost" publicKeyToken="31bf3856ad364e35" />
        <bindingRedirect oldVersion="0.0.0.0-5.2.3.0" newVersion="5.2.3.0" />
      </dependentAssembly>
      <dependentAssembly xmlns="">
        <assemblyIdentity name="System.Web.WebPages.Razor" publicKeyToken="31bf3856ad364e35" />
        <bindingRedirect oldVersion="1.0.0.0-3.0.0.0" newVersion="3.0.0.0" />
      </dependentAssembly>

Expected result

In clean install web.config, nodes for dependent assemblies do not have namespace attribute that is empty.

      <dependentAssembly>
        <assemblyIdentity name="System.Web.Http" publicKeyToken="31BF3856AD364E35" />
        <bindingRedirect oldVersion="0.0.0.0-5.2.3.0" newVersion="5.2.3.0" />
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="System.Net.Http.Formatting" publicKeyToken="31bf3856ad364e35" />
        <bindingRedirect oldVersion="0.0.0.0-5.2.3.0" newVersion="5.2.3.0" />
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="System.Web.Http.WebHost" publicKeyToken="31bf3856ad364e35" />
        <bindingRedirect oldVersion="0.0.0.0-5.2.3.0" newVersion="5.2.3.0" />
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="System.Web.WebPages.Razor" publicKeyToken="31bf3856ad364e35" />
        <bindingRedirect oldVersion="1.0.0.0-3.0.0.0" newVersion="3.0.0.0" />
      </dependentAssembly>

Screenshots

If applicable, provide screenshots to help explain your problem.

Error log

Paste the error log that is related to this issue.

Additional context

Add any other context about the bug that may be helpful for resolution.

Affected version

• 9.4.0 release candidate

[bdukes]

Alright, I think I’ve tracked this down. It appears this all came from the 8.0.0 install. There are a bunch of XML Merge files that ran in that install, including https://github.com/dnnsoftware/Dnn.Platform/blob/584b0f54bd6b6d237594dd9f96053f14db0b1a53/DNN Platform/Website/Install/Config/08.00.00.22.config and https://github.com/dnnsoftware/Dnn.Platform/blob/584b0f54bd6b6d237594dd9f96053f14db0b1a53/DNN Platform/Website/Install/Config/08.00.00.30.config. These added or updated dependentAssembly elements for the following assemblies:

• Newtonsoft.Json
• System.Web.Http
• System.Net.Http.Formatting
• System.Web.Http.WebHost
• System.Web.WebPages.Razor

However, the xmlns attribute is missing on these, so when adding those nodes, they explicitly clear the parent namespace using xmlns="". As a result, these dependentAssembly do nothing and no binding redirect is created. But not always, because when the matching dependentAssembly element already existed, it was overwritten using text, not using the API (https://github.com/dnnsoftware/Dnn.Platform/blob/release/8.0.0/DNN Platform/Library/Services/Installer/XmlMerge.cs#L493), and therefore the xmlns="" was not inserted. This is why this issue is inconsistent, it depends on the state of the web.config at the time of the upgrade.

So, I believe, your issue stems from those binding redirects not being in place as they should, and therefore not effectively helping you when you’re compiling against different versions than what is in the bin.

As far as I can see, there are two action items from this:

• DNN should find and rewrite invalid binding redirects with xmlns="" (carefully, so that we don’t activate a binding redirect that is no longer valid). This should happen upon upgrade to some future version.
• The XmlMerge logic for handling collision="overwrite" has already been fixed, but collision="save" still sets InnerXml instead of using the APIs correctly (which, in this case, masked the fact that the merge files were wrong). See https://github.com/dnnsoftware/Dnn.Platform/blob/development/DNN Platform/Library/Services/Installer/XmlMerge.cs#L562

[donker]

Also: I’ve tried the same with 9.3.2 and this is also the same result. So it looks like this wasn’t introduced in 9.4.0 but earlier.