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

Created on 3 Sep 2019 · 10Comments · Source: dnnsoftware/Dnn.Platform

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

Clean install DNN 9.4.0 RC1 using DNN_Platform_9.4.0-rc1.20742_Install.zip.
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
And module to page. Module is working.

Upgrade DNN scenario

Clean install DNN 7.4.2.
Upgrade to DNN 9.4.0 RC1 using DNN_Platform_9.4.0-rc1.20742_Upgrade.zip.
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
And module to page. Module is not working. We get exception:

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

[x] 9.4.0 release candidate

Bug

Source

tvatavuk

All 10 comments

There is a currently known limitation with 2sxc and the 9.4.0 RC. I know that Daniel is working on a fix.

mitchelsellers on 3 Sep 2019

@mitchelsellers actually @tvatavuk is working on it, and ran into this separate problem. The issue seems to be, that the DNN installer adds more unnecessary entries, which then cause this. So this is a DNN-update issue, unrelated to the Dependency Injection issue of .net core which we are solving.

iJungleboy on 3 Sep 2019

@iJungleboy Thanks for this, it looked a bit different, I'll have a look at this to see what we can find.

We don't have any changes in this area that are part of the 9.4.0 release, so this one is a bit odd.

mitchelsellers on 3 Sep 2019

@mitchelsellers just fyi: as far as I understood @tvatavuk a clean 9.4 doesn't have this problem, but an upgraded one does.

iJungleboy on 3 Sep 2019

I can replicate this @tvatavuk, @iJungleboy. It appears that you don't need to install 2sxc to get these xmlns="" in the web.config. They happen regardless. But I've also seen this in other 9.x installations. And those just work fine. Is there anything you can think of that causes the 2sxc to fail because of this?

donker on 3 Sep 2019

👍1

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.

donker on 3 Sep 2019

👍1

@donker thx for verifying. @tvatavuk will give some more infos, but 2sxc uses Razor and I believe the webhost, probably also system.http.

My guess is that the versions in the web.config are off. For example, the DLL versions for Razor are 3.0.2 (not 3.0.0) and our DLLs probably bind to 2.x or similar, and are now redirected to a 3.0, which doesn't exist. But that's just a guess - basically these entries don't seem to contribute anything, so I can't guess why they were added in DNN, especially only in upgrade routines.

iJungleboy on 4 Sep 2019

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%20Platform/Website/Install/Config/08.00.00.22.config and https://github.com/dnnsoftware/Dnn.Platform/blob/584b0f54bd6b6d237594dd9f96053f14db0b1a53/DNN%20Platform/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%20Platform/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%20Platform/Library/Services/Installer/XmlMerge.cs#L562

bdukes on 4 Sep 2019

👍1

@bdukes that sounds impressive 👍. I must admit I didn't understand all of it, but that's because I've never looked at the DNN installer/upgrade process. Just to understand the situation:

This seems to affect all systems which started as a pre 8.0.0 and were upgraded afterwards
It doesn't effect systems that started their life as a post 8.0.0.3
...meaning that the web.config systems "in the wild" have 2 inconsistent states as of now (correct?)

And to fix it, we _should_:

correct how the xml-merging happens (because it's faulty)
... - this would also modify how future upgrades actually run the 8.0 scripts, but this also risks us creating a third possible state for the web.config
find a way to re-sync the inconsistencies of installations out there, and ideally remove the concerned bits which should never have been there in the first place

Is this correct? thx!

iJungleboy on 4 Sep 2019

Merded in #2979