-
Notifications
You must be signed in to change notification settings - Fork 753
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
Comments
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 Your insights on this matter would be greatly appreciated. |
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
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:
|
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. |
as a workaround, you can binding different version of the assembly to different dll files: |
Another possible fix is to (in this order):
DLL newVersion assignments via Binding Redirect:
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 ;) |
@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? |
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? |
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. |
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": |
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. |
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 |
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. |
@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.
Is there an existing issue for this?
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?
Detailed steps and discussion are available at 2sic/2sxc#3511.
Current Behavior
System.Runtime.CompilerServices.Unsafe.dll
version 6.0.0.0 in the bin directory.Expected Behavior
The DNN upgrade process should not overwrite newer DLLs with older versions without appropriately handling assembly bindings. It should:
Relevant log output
Anything else?
Affected Versions
9.13.6 (latest release)
What browsers are you seeing the problem on?
No response
Code of Conduct
The text was updated successfully, but these errors were encountered: