[Bug]: DNN 9.13.6 Upgrade Overwrites Newer DLL, Breaking 2sxc Module #6222

tvatavuk · 2024-11-27T12:26:29Z

Is there an existing issue for this?

I have searched the existing issues

What happened?

When upgrading a DNN 9.13.4 site with 2sxc 18.4 to DNN 9.13.5+, the 2sxc module stops working. The DNN upgrade overwrites System.Runtime.CompilerServices.Unsafe.dll version 6.0.0.0 with an older version 4.0.4.1, causing compatibility issues with 2sxc.

The DNN upgrade should not break the 2sxc module. It should preserve newer versions of DLLs or handle dependencies correctly to ensure that modules depending on newer versions continue to function.

Steps to reproduce?

Install DNN 9.13.4 with the 2sxc 18.4 module.
Verify that 2sxc is working correctly.
Upgrade DNN to version 9.13.6.
Observe that the 2sxc module stops working and throws exceptions.

Detailed steps and discussion are available at 2sic/2sxc#3511.

Current Behavior

The 2sxc 18+ module installs System.Runtime.CompilerServices.Unsafe.dll version 6.0.0.0 in the bin directory.
After upgrading to DNN 9.13.5+, the DLL is overwritten with version 4.0.4.1.
The web.config and the Assemblies table in the DNN database still reference version 6.0.0.0.
As a result, 2sxc, which depends on version 6.0.0.0, fails to work and throws exceptions.

Expected Behavior

The DNN upgrade process should not overwrite newer DLLs with older versions without appropriately handling assembly bindings. It should:

Preserve newer versions of DLLs if they exist.
Update web.config and the Assemblies table to reflect any changes in DLL versions.
Ensure that modules depending on newer DLL versions continue to function after the upgrade.

Relevant log output

System.ArgumentNullException: Value cannot be null. Parameter name: collection
   at System.ThrowHelper.ThrowArgumentNullException(ExceptionArgument argument)
   at System.Collections.Generic.List`1.InsertRange(Int32 index, IEnumerable`1 collection)
   at ToSic.Eav.Apps.Services.AppDataStackService.GetStack(AppThingsIdentifiers target, IEntity viewPart) in C:\Projects\2sxc\eav-server\ToSic.Eav.Core\Apps\Services\AppDataStackService.cs:line 40
   at ToSic.Eav.Apps.Services.AppDataStackService.GetStack(String part, IEntity viewPart) in C:\Projects\2sxc\eav-server\ToSic.Eav.Core\Apps\Services\AppDataStackService.cs:line 31
   at ToSic.Lib.Helpers.GetOnce`1.Get(Func`1 generator) in C:\Projects\2sxc\eav-server\ToSic.Lib.Core\Helpers\GetOnce.cs:line 38
   at ToSic.Sxc.LookUp.Internal.SxcAppDataConfigProvider.GetLookupEngineForContext(IContextOfSite context, IApp appForLookup, IBlock blockForLookupOrNull) in C:\Projects\2sxc\2sxc\Src\Sxc\ToSic.Sxc\LookUp\Internal\SxcAppDataConfigProvider.cs:line 63
   at ToSic.Sxc.LookUp.Internal.SxcAppDataConfigProvider.GetDataConfiguration(EavApp app, AppDataConfigSpecs specs) in C:\Projects\2sxc\2sxc\Src\Sxc\ToSic.Sxc\LookUp\Internal\SxcAppDataConfigProvider.cs:line 21
   at ToSic.Eav.Apps.Internal.EavApp.<get_AppDataConfig>b__22_0() in C:\Projects\2sxc\eav-server\ToSic.Eav.Apps\Eav.Apps.Internal\App\EavApp_Data.cs:line 17
   at ToSic.Lib.Helpers.GetOnce`1.Get(Func`1 generator) in C:\Projects\2sxc\eav-server\ToSic.Lib.Core\Helpers\GetOnce.cs:line 38
   at ToSic.Eav.Apps.Internal.EavApp.<get_ConfigurationProvider>b__19_0() in C:\Projects\2sxc\eav-server\ToSic.Eav.Apps\Eav.Apps.Internal\App\EavApp_Data.cs:line 11
   at ToSic.Lib.Helpers.GetOnce`1.Get(Func`1 generator) in C:\Projects\2sxc\eav-server\ToSic.Lib.Core\Helpers\GetOnce.cs:line 38
   at ToSic.Eav.Apps.Internal.EavApp.BuildData[TDataSource,TResult]() in C:\Projects\2sxc\eav-server\ToSic.Eav.Apps\Eav.Apps.Internal\App\EavApp_Data.cs:line 39
   at ToSic.Eav.Apps.Internal.EavApp.get_Data() in C:\Projects\2sxc\eav-server\ToSic.Eav.Apps\Eav.Apps.Internal\App\EavApp_Data.cs:line 33
   at ToSic.Sxc.Web.Internal.JsContext.JsContextAll.GetJsContext(String systemRootUrl, IBlock block, String errorCode, List`1 exsOrNull, RenderStatistics statistics) in C:\Projects\2sxc\2sxc\Src\Sxc\ToSic.Sxc\Web\Internal\JsContext\JsContextAll.cs:line 60
   at ToSic.Sxc.Blocks.Internal.Render.RenderingHelper.ContextAttributes(Int32 instanceId, Int32 contentBlockId, Boolean includeEditInfos, Boolean includeJsApiContext, String errorCode, List`1 exsOrNull, RenderStatistics statistics) in C:\Projects\2sxc\2sxc\Src\Sxc\ToSic\ToSic.Sxc\Blocks\Internal\Render\RenderingHelper.cs:line 77
   at ToSic.Sxc.Blocks.Internal.Render.RenderingHelper.WrapInContext(String content, NoParamOrder noParamOrder, Int32 instanceId, Int32 contentBlockId, Boolean editContext, Boolean jsApiContext, String tag, Boolean addLineBreaks, String errorCode, List`1 exsOrNull, RenderStatistics statistics) in C:\Projects\2sxc\2sxc\Src\Sxc\ToSic\ToSic.Sxc\Blocks\Internal\Render\RenderingHelper.cs:line 56
   at ToSic.Sxc.Blocks.Internal.BlockBuilder.RenderInternal(RenderSpecs specs) in C:\Projects\2sxc\2sxc\Src\Sxc\ToSic\ToSic.Sxc\Blocks\Internal\BlockBuilder\BlockBuilder_Render.cs:line 88

Anything else?

This issue has been reported and discussed in the 2sxc repository: 2sic/2sxc#3511.
The problem appears to have started with DNN version 9.13.5, where the upgrade package includes the older System.Runtime.CompilerServices.Unsafe.dll version 4.0.4.1.
Manual workaround i just to copy System.Runtime.CompilerServices.Unsafe.dll version 6.0.0.0. over version 4.0.4.1. in bin folder, or reinstall 2sxc module

Affected Versions

9.13.6 (latest release)

What browsers are you seeing the problem on?

No response

Code of Conduct

I agree to follow this project's Code of Conduct

The text was updated successfully, but these errors were encountered:

tvatavuk · 2024-11-27T12:55:54Z

Request for Insights

@mitchelsellers, @bdukes, and @valadas:

Is there any specific limitation or reason in DNN versions 9.13.5 and above that necessitates the current behavior regarding the System.Runtime.CompilerServices.Unsafe.dll dependency? Specifically, the upgrade process overwriting newer DLLs with older versions seems to cause compatibility issues with modules like 2sxc that depend on the newer DLL versions.

Your insights on this matter would be greatly appreciated.

jeremy-farrance · 2024-11-27T14:43:57Z

I am not sure if this helps, but in DNN v9.13.06 with 2sxc 8.0.4 re-installed (so its fixed), you can find 3 copies/versions of System.Runtime.CompilerServices.Unsafe.dll in /bin/* as follows:

\bin\roslyn, 4.700.18.56404
\bin]Imageflow, 4.6.28619.1
\bin, 6.0.21.52210

The version in the \bin folder of the DNN v9.13.06 upgrade zip is 4.6.28619.1.

Another thing worth noting is that 2sxc manages this DLL on behalf of ImageFlow with the following binding redirect (since at least 2sxc v17:

<dependentAssembly xmlns="urn:schemas-microsoft-com:asm.v1">
    <assemblyIdentity name="System.Runtime.CompilerServices.Unsafe" publicKeyToken="b03f5f7f11d50a3a" />
    <bindingRedirect oldVersion="0.0.0.0-4.0.4.1" newVersion="4.0.4.1" xmlns="urn:schemas-microsoft-com:asm.v1" />
    <codeBase version="4.0.4.1" href="bin\Imageflow\System.Runtime.CompilerServices.Unsafe.dll" xmlns="urn:schemas-microsoft-com:asm.v1" />
    <bindingRedirect oldVersion="4.0.4.2-32767.32767.32767.32767" newVersion="6.0.0.0" />
</dependentAssembly>

mitchelsellers · 2024-11-27T15:06:42Z

This is an item included by DLL by default, so unzipping the upgrade package overwrites, there is no possibility to protect this version at upgrade.

It is possible, depending on usage for this also to be extracted as a package so version number rules could be respected but it would need to be reviewed.

This is a reason why upgrading versions of core distributed components should be discouraged/avoided wherever possible. As there are limitations of what is possible due to the way the DNN upgrades are applied.

zyhfish · 2024-11-27T15:19:24Z

as a workaround, you can binding different version of the assembly to different dll files:
https://stackoverflow.com/questions/638310/how-to-operate-with-multiple-assembly-versions-in-private-folders-using-config

jeremy-farrance · 2024-11-27T15:24:16Z

Another possible fix is to (in this order):

before upgrading to DNN v9.13.06 (while still on .04), copy the System.Runtime.CompilerServices.Unsafe.dll from /bin to /bin/2sxc
find and modify the existing binding redirect (working example below) in /web.config
upgrade to DNN v9.13.06 (and 2sxc does not break**)

DLL newVersion assignments via Binding Redirect:

  <dependentAssembly xmlns="urn:schemas-microsoft-com:asm.v1">
        <assemblyIdentity name="System.Runtime.CompilerServices.Unsafe" publicKeyToken="b03f5f7f11d50a3a" />
        <bindingRedirect oldVersion="0.0.0.0-4.0.4.1" newVersion="4.0.4.1" xmlns="urn:schemas-microsoft-com:asm.v1" />
        <bindingRedirect oldVersion="4.0.4.2-4.32767.32767.32767" newVersion="4.5.0.0" />
        <bindingRedirect oldVersion="5.0.0.0-32767.32767.32767.32767" newVersion="6.0.0.0" />
        <codeBase version="4.0.4.1" href="bin\Imageflow\System.Runtime.CompilerServices.Unsafe.dll" xmlns="urn:schemas-microsoft-com:asm.v1" />
        <codeBase version="6.0.0.0" href="bin\2sxc\System.Runtime.CompilerServices.Unsafe.dll" xmlns="urn:schemas-microsoft-com:asm.v1" />
  </dependentAssembly>

In English, this tells your app which DLL to use based on the version needed. 0 to 4.0.4.1 for ImageFlow, 4.0.4.2 to 5.* use the default (in /bin), and 6+ uses the 2sxc folder one. More help on this is available here.

** and stress is greatly reduced ;)

iJungleboy · 2024-11-28T11:04:25Z

This is an item included by DLL by default, so unzipping the upgrade package overwrites, there is no possibility to protect this version at upgrade.

It is possible, depending on usage for this also to be extracted as a package so version number rules could be respected but it would need to be reviewed.

This is a reason why upgrading versions of core distributed components should be discouraged/avoided wherever possible. As there are limitations of what is possible due to the way the DNN upgrades are applied.

@mitchelsellers AFAIK 2sxc never upgraded an existing DNN DLL - this is a brand-new DLL for DNN since 9.13.5. So this is a breaking change introduced by DNN without respecting the versions table...

So DNN could at least include the latest version, instead of an old one.

@tvatavuk is what I wrote above correct?

leedavi · 2024-11-28T14:11:20Z

I think Daniel is right. I understand it's not for DNN community to police what third party modules use what dlls, but it's strange that DNN did not use the latest version. Is there a reason for this?

mitchelsellers · 2024-11-28T18:17:39Z

We will have to review then why this came in, I'm not aware of dependency updates they were in this version only.

Because it is in the initial zip, there is no way to respect the DLL table.

It's a holiday here in the US. I'll try to review asap if no one else has time.

jeremy-farrance · 2024-11-28T18:21:03Z

My guess would be that there has been a LOT of "version bump" clean up on dependencies, most likely it is a sub (sub) dependency that was brought in to play. Likely recent stuff here...

Searching Pull Requests for "unsafe":
https://github.com/dnnsoftware/Dnn.Platform/pulls?q=is%3Apr+Unsafe

mitchelsellers · 2024-11-28T19:10:05Z

Yeah, I'm looking there. THe biggest thing I'm seeing so far is that is only in Test projects not normal ones, so not sure why it would even be in the package.

mitchelsellers · 2024-11-28T19:14:52Z

Just an update for everyone, I have found where this started coming in, not 100% sure what package actually has it, but we can at least start to figure out where to look from here.

This file was introduced in 9.13.5, and is also here in 9.13.6

So this issue impacts BOTH 9.13.5 and 9.13.6

jeremy-farrance · 2024-11-28T19:21:58Z

For the record, I triple checked and these 5 DLLs (red line to the right) were introduced in 9.13.05. There could be others, I was only checking the bottom of the list... (this clip is from the DNN_Platform_9.13.5_Install.zip**)

** all five files also are there in .6_Install.zip and both _Upgrade.zips.

iJungleboy · 2024-11-29T06:57:38Z

@mitchelsellers thanks for prioritizing this 🙏🏽

This may fix dnnsoftware#6222 but I ran out of time to test, a clean install did work fine and that's all I had time to test for now. I think there are a couple other dlls in the issue we could handle here or elsewhere and we need to test upgrade scenarios from 9.13.4,5,6 to be sure.

skarpik · 2024-12-15T06:07:53Z

DNN 9.13.7-rc1 appears to resolve the problem. I did a test upgrading a DNN 2sxc v9.13.4, 2sxc v18.04.00 to DNN 9.13.7-rc1. There were no issues.

tvatavuk added the Status: New label Nov 27, 2024

tvatavuk mentioned this issue Nov 27, 2024

Upgrade to DNN v9.13.6 breaks 2sxc v18.04.00 (DNN DLL issue) 2sic/2sxc#3511

Closed

valadas mentioned this issue Nov 29, 2024

Added sub-dependencies of AspNetWebApi to package #6227

Merged

donker closed this as completed in #6227 Dec 6, 2024

donker closed this as completed in 2054203 Dec 6, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[Bug]: DNN 9.13.6 Upgrade Overwrites Newer DLL, Breaking 2sxc Module #6222

[Bug]: DNN 9.13.6 Upgrade Overwrites Newer DLL, Breaking 2sxc Module #6222

tvatavuk commented Nov 27, 2024

tvatavuk commented Nov 27, 2024

jeremy-farrance commented Nov 27, 2024 •

edited

Loading

mitchelsellers commented Nov 27, 2024

zyhfish commented Nov 27, 2024

jeremy-farrance commented Nov 27, 2024 •

edited

Loading

iJungleboy commented Nov 28, 2024

leedavi commented Nov 28, 2024

mitchelsellers commented Nov 28, 2024

jeremy-farrance commented Nov 28, 2024 •

edited

Loading

mitchelsellers commented Nov 28, 2024

mitchelsellers commented Nov 28, 2024

jeremy-farrance commented Nov 28, 2024 •

edited

Loading

iJungleboy commented Nov 29, 2024

skarpik commented Dec 15, 2024

[Bug]: DNN 9.13.6 Upgrade Overwrites Newer DLL, Breaking 2sxc Module #6222

[Bug]: DNN 9.13.6 Upgrade Overwrites Newer DLL, Breaking 2sxc Module #6222

Comments

tvatavuk commented Nov 27, 2024

Is there an existing issue for this?

What happened?

Steps to reproduce?

Current Behavior

Expected Behavior

Relevant log output

Anything else?

Affected Versions

What browsers are you seeing the problem on?

Code of Conduct

tvatavuk commented Nov 27, 2024

Request for Insights

jeremy-farrance commented Nov 27, 2024 • edited Loading

mitchelsellers commented Nov 27, 2024

zyhfish commented Nov 27, 2024

jeremy-farrance commented Nov 27, 2024 • edited Loading

iJungleboy commented Nov 28, 2024

leedavi commented Nov 28, 2024

mitchelsellers commented Nov 28, 2024

jeremy-farrance commented Nov 28, 2024 • edited Loading

mitchelsellers commented Nov 28, 2024

mitchelsellers commented Nov 28, 2024

jeremy-farrance commented Nov 28, 2024 • edited Loading

iJungleboy commented Nov 29, 2024

skarpik commented Dec 15, 2024

jeremy-farrance commented Nov 27, 2024 •

edited

Loading

jeremy-farrance commented Nov 27, 2024 •

edited

Loading

jeremy-farrance commented Nov 28, 2024 •

edited

Loading

jeremy-farrance commented Nov 28, 2024 •

edited

Loading