Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
2 tasks done
tvatavuk opened this issue Nov 27, 2024 · 13 comments · Fixed by #6227
Closed
2 tasks done

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

tvatavuk opened this issue Nov 27, 2024 · 13 comments · Fixed by #6227

Comments

@tvatavuk
Copy link

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?

  1. Install DNN 9.13.4 with the 2sxc 18.4 module.
  2. Verify that 2sxc is working correctly.
  3. Upgrade DNN to version 9.13.6.
  4. 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
@tvatavuk
Copy link
Author

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
Copy link
Contributor

jeremy-farrance commented Nov 27, 2024

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
Copy link
Contributor

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
Copy link
Contributor

zyhfish commented Nov 27, 2024

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
Copy link
Contributor

jeremy-farrance commented Nov 27, 2024

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
Copy link
Contributor

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
Copy link
Contributor

leedavi commented Nov 28, 2024

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
Copy link
Contributor

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
Copy link
Contributor

jeremy-farrance commented Nov 28, 2024

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
Copy link
Contributor

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
Copy link
Contributor

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
Copy link
Contributor

jeremy-farrance commented Nov 28, 2024

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**)

image

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

@iJungleboy
Copy link
Contributor

@mitchelsellers thanks for prioritizing this 🙏🏽

valadas added a commit to valadas/Dnn.Platform that referenced this issue Nov 29, 2024
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.
@donker donker closed this as completed in 2054203 Dec 6, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants