Upgrade to DNN v9.13.6 breaks 2sxc v18.04.00

[skarpik]

I'm submitting a

[x] bug report => search github for a similar issue before submitting

...about

[x] admin experience UI

Current Behavior / Expected Behavior

Upgrading a DNN v9.13.4 (2sxc v18.04.00) website to DNN v9.13.6 breaks both 2sxc Content and Apps.

Content Page - Pre-upgrade

Content Page - Post-upgrade

App Page (Photo Gallery) - Pre-upgrade

App Page (Photo Gallery) - Post-upgrade

Sample Error Message

Stopping and restarting the website (cycling IIS) does not solve the problem.

Re-installing 2sxc v18.04.00, logging out and refreshing the browser seems to fix everything.

I'm guessing that the issue might be with 2sxc but it could very well be with the DNN upgrade. I found the same error with 2sxc v18.01.00.

Instructions to Reproduce the Problem

1. Created a test website with DNN v9.13.4 and 2sxc v18.04.00
2. Added a page with Basic Content and a page with a Photo Gallery
3. Upgraded to DNN v9.13.6 (breaks 2sxc)
4. Re-installed 2sxc v18.04.00 (fixes everything)

Your environment

• 2sxc version(s): 18.04.00
• Browser: all
• DNN: 9.13.6
• Hosting platform: IIS
• Language: English

[valadas]

Can you check the files in portals/_default/logs to see if there are any clues there ?

[trouble2]

Perhaps related: #3440
Only in my case installing the update again did not fix anything and it was in an older version...

[aspelt]

I have the same issue when upgrading with 2sxc v17.10.00
Upgrading a DNN v9.13.4 (2sxc v17.10.00) website to DNN v9.13.6 breaks both 2sxc Content and Apps.

A re-install of 2scx version 17.10.00 fixes the issue.

[aspelt]

DotNetNuke.Services.Exceptions.Exceptions - FriendlyMessage="The: App is not available this moment." ctrl="ASP.desktopmodules_tosic_sexycontent_view_ascx" exc="System.Exception: something went wrong - can't find type in app, but it's not a global type, so I must cancel
at ToSic.Eav.Apps.Internal.Work.AppInitializer.MetadataEnsureTypeAndSingleEntity(IAppState appStateRaw, AddContentTypeAndOrEntityTask cTypeAndOrEntity) in C:\Projects\2sxc\eav-server\ToSic.Eav.Apps\Eav.Apps.Internal\Work\AppCreate\AppInitializer.cs:line 139
at System.Collections.Generic.List1.ForEach(Action1 action)
at ToSic.Eav.Apps.Internal.Work.AppInitializer.InitializeApp(IAppState appState, String newAppName, CodeRefTrail codeRefTrail) in C:\Projects\2sxc\eav-server\ToSic.Eav.Apps\Eav.Apps.Internal\Work\AppCreate\AppInitializer.cs:line 94
at ToSic.Eav.Apps.Internal.Work.AppInitializedChecker.EnsureAppConfiguredAndInformIfRefreshNeeded(IAppState appState, String appName, CodeRefTrail codeRefTrail, ILog parentLog) in C:\Projects\2sxc\eav-server\ToSic.Eav.Apps\Eav.Apps.Internal\Work\AppCreate\AppInitializedChecker.cs:line 21
at ToSic.Eav.Persistence.Efc.Efc11Loader.AppStateInitialized(Int32 appId, CodeRefTrail codeRefTrail) in C:\Projects\2sxc\eav-server\ToSic.Eav.Persistence.Efc\Efc11Loader_App.cs:line 114
at ToSic.Eav.Caching.AppsCacheBase.GetOrBuild(IAppLoaderTools tools, IAppIdentity appIdentity, String primaryLanguage) in C:\Projects\2sxc\eav-server\ToSic.Eav.Core\Caching\Apps\AppsCacheBase.cs:line 134
at ToSic.Eav.Apps.Internal.EavApp.Init(ISite site, IAppIdentityPure appIdentity, AppDataConfigSpecs dataSpecs) in C:\Projects\2sxc\eav-server\ToSic.Eav.Apps\Eav.Apps.Internal\App\EavApp.cs:line 88
at ToSic.Sxc.Blocks.Internal.BlockBase.CompleteInit(IBlockBuilder rootBuilderOrNull, IBlockIdentifier blockId, Int32 blockNumberUnsureIfNeeded) in C:\Projects\2sxc\2sxc\Src\Sxc\ToSic.Sxc\Blocks\Internal\BlockOfBase.cs:line 77
at ToSic.Sxc.Blocks.Internal.BlockFromModule.Init(IContextOfBlock ctx) in C:\Projects\2sxc\2sxc\Src\Sxc\ToSic.Sxc\Blocks\Internal\BlockOfModule.cs:line 22
at ToSic.Sxc.Blocks.Internal.ModuleAndBlockBuilder.BuildBlock[TPlatformModule](TPlatformModule module, Nullable1 page) in C:\Projects\2sxc\2sxc\Src\Sxc\ToSic.Sxc\Blocks\Internal\ModuleAndBlockBuilder.cs:line 37 at ToSic.Sxc.Dnn.View.<get_Block>b__5_1() in C:\Projects\2sxc\2sxc\Src\Dnn\ToSic.Sxc.Dnn\View.ascx.cs:line 35 at ToSic.Lib.Logging.LogCallBaseExtensions.DoInTimer[TResult](ILogCall logCall, Func1 action) in C:\Projects\2sxc\eav-server\ToSic.Lib.Core\Logging\LogCall\LogCallBaseExtensions.cs:line 24
at ToSic.Lib.Logging.ILog_Properties.Getter[TProperty](ILog log, Func`1 getter, Boolean timer, Boolean enabled, String message, String parameters, String cPath, String cName, Int32 cLine) in C:\Projects\2sxc\eav-server\ToSic.Lib.Core\Logging\Log\ILog_Properties.cs:line 38
at ToSic.Sxc.Dnn.View.get_Block() in C:\Projects\2sxc\2sxc\Src\Dnn\ToSic.Sxc.Dnn\View.ascx.cs:line 35

[jeremy-farrance]

Okay, I found a small website which was upgraded over the years from a starting install of DNN v7.03.04 and was currently DNN v9.13.04. 2sxc was installed and only at v15.08. Both apps and content module/app were in use across quite a few pages.

I upgraded DNN to v9.13.06. Same results as pictured above, both Apps and Content module/app showing same errors; "Data is missing...", "Something went wrong..." etc.

So then I install 2sxc v16.07 and this fixed all. Everything is working again, I can find no problems with the site or 2sxc stuff.

[iJungleboy]

Not really sure what this is.

My guess ATM would be that maybe DNN 9.13.6 replaces some previously "standard" .net core DLLs?

[jeremy-farrance]

@iJungleboy - my guess is that its something to do with the info returned by ServerInfo that changed in v9.13.05 I updated this so that we got the proper 3 part version numbers for the .NET Framework Product Version DNN reports. So now we see "4.8.1" instead of "4.8" when its running on 4.8.1 actually.

However, this introduced a serious bug in v9.13.05; if the .NET Product Version was 4.8.0 there was a bug in the .ToString of the Version system type (not sure I have this detail stated accurately). This threw an error and get ServerInfo failed. Hence the quick fix and release of DNN v9.13.06...

When 2sxc starts up, I assume it calls ServerInfo or related, either on the backend or via WebApi. If you examine the files changed in Brian Dukes fix (v9.13.06), I am pretty sure you will spot something that affects 2sxc startup.
dnnsoftware/Dnn.Platform#6201

[valadas]

@jeremy-farrance it is the best theory so far

[iJungleboy]

@tvatavuk could you look into this?

[iJungleboy]

What I find strange is that (pls confirm)

1. A restart doesn't fix it
2. A re-install of 2sxc (same version) fixes it

this doesn't sound like a DNN-Version-Check issue

[aspelt]

I can confirm that a restart of IIS didn't fix the issue.

[tvatavuk]

• The 2sxc module installs System.Runtime.CompilerServices.Unsafe.dll version 6.0.0.0 in the bin directory and add related references in web.config and Assemblies table in DNN database.
• As part of upgrading to DNN 9.13.6, the DLL is overwritten with version 4.0.4.1. while 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.

Issue is reported on DNN GH dnnsoftware/Dnn.Platform#6222 because the DNN upgrade process probably should not overwrite newer DLLs with older versions (also without appropriately handling assembly bindings). Ideally it should:

• Preserve newer versions of DLLs if they exist.
• Update web.config and the Assemblies table to reflect any changes in DLL versions.

This can ensure that modules depending on newer DLL versions continue to function after the upgrade.
Still in some cases there are limitation, so first we should check with @mitchelsellers, @bdukes and @valadas to evaluate options.

Until proper fix, simple workarounds are:

• reinstall 2sxc module or,
• manually copy System.Runtime.CompilerServices.Unsafe.dll version 6.0.0.0. from 2sxc ZIP over version 4.0.4.1. in bin folder

[jeremy-farrance]

I have posted a possible "Alternate Fix" by modifying the existing binding redirect (for System.Runtime.CompilerServices.Unsafe) to account for all 3 in-use versions of the DLL.

Read from here on down:
dnnsoftware/Dnn.Platform#6222 (comment)

[jeremy-farrance]

I am reposting this here in case someone feels this workaround is good enough for now while "the DNN powers that be" sort things out. I appreciate hearing if anyone has success with this. I've got 4 sites upgraded to DNN 9.13.06 with 2sxc 18.03+ and no issues. Cheers!

---

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

[valadas]

Might have a fix here, waiting on reviews/testing dnnsoftware/Dnn.Platform#6227

[tvatavuk]

@jeremy-farrance, it’s impressive how quickly you identified, proposed, and documented a solution for adjusting assembly bindings in the web.config to prevent issues with 2sxc after upgrading DNN using the DNN_Platform_9.13.5_Upgrade.zip or DNN_Platform_9.13.6_Upgrade.zip. Your proactive approach and detailed workaround are invaluable to the community. 👏

I’d like to add some context about managing these bindings. Maintaining and adjusting bindings in web.config can be hard. For 2sxc deployments, we strive to rely on existing DNN mechanisms for managing these configurations, minimizing manual intervention where possible. Every 2sxc upgrade includes steps to verify and adjust relevant bindings to align with the expected environment.

However, maintaining and testing the XPath logic responsible for these adjustments is complex and time-intensive. While we aim for robust solutions, it's challenging to account for every possible configuration, especially for edge cases outside the expected scenarios.

My suggestion is that after the next DNN upgrade, it might be beneficial to revert custom binding adjustments to ensure they align with the original expectations of 2sxc. If this isn't feasible, be prepared for potential manual updates to the web.config bindings during future 2sxc upgrades.

Thank you for your insight, effort, and ongoing support for both 2sxc and DNN. Keep up the excellent work—you’re making a real difference! 🫶

I am reposting this here in case someone feels this workaround is good enough for now while "the DNN powers that be" sort things out. I appreciate hearing if anyone has success with this. I've got 4 sites upgraded to DNN 9.13.06 with 2sxc 18.03+ and no issues. Cheers!

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

[jeremy-farrance]

Yup, I can definitely see how my fix could cause problems in the future. I've noted the two sites where I did this and set a reminder to undo it in January or so after we are properly running on DNN 9.13.07+ and 2sxc 18.05 or higher. Thanks!