Fixed an issue with wrong localization detection#6505
Fixed an issue with wrong localization detection#6505mitchelsellers merged 1 commit intodnnsoftware:developfrom
Conversation
I did a `git bisect` which pointed me to the commits in dnnsoftware#6038 to rollup the sql scripts for v10. This made no sense to me since it's not really related to web.config and @uzmannazari pointed out in dnnsoftware#6503 that a similar issue was caused by the LocalizationModule missing from the web.config. Also I could not reproduce the issue on upgrades. Then I thought since we have that v10 rollup, it uses the 10.00.00.config for the web.config xml merge scripts and up. Investigating the commit history of that file and comparing with 9.8.0 one I found that in dnnsoftware#4251, a bugfix was done to insure that the LocalizationModule is right after the UrlRewriteModule. This means tha upon upgrades it would be in the right place but with clean installs, that would never run and it was also missing from the base web.config, thus making it not be there at all. I was debating between putting this fix in the 10.00.00.config or just in the web.config I thought the web.config is fine as upon upgrades, the order would already have been fixed (as long as we document to upgrade to latest v9 before upgrading to v10). For clean installs it would just already be at the right place to start with.
david-poindexter
left a comment
There was a problem hiding this comment.
Excellent @valadas - thank you so much! 🎉
|
@valadas For instance, the ServiceRequestScopeModule, which is clearly defined in the config merge file, never gets added to the output web.config. This indicates a broader problem—it seems the installer is unable to properly read or apply the XML config merge files during installation. We confirmed this by adding detailed logging to the XmlMerge.cs logic and saw that neither the expected InsertNode actions were triggered, nor were the relevant configuration files even being processed as expected. This goes beyond a simple placement or syntax issue; it looks like the config merge engine is either silently skipping or failing to locate and process valid .config files, which can lead to a broken runtime environment after a clean install. If needed, I can provide the logs and the exact config files we used for testing. |
|
@uzmannazari absolutely, the more information the better. |
|
Thanks! I’ve prepared the full logs and the related config files we used during testing. They clearly show that the 10.00.00.config was reached during installation, but certain actions like insertbefore or insertafter were never executed—even though other parts of the same config file were successfully applied. I'll upload everything shortly for your review. Let me know if you'd prefer a GitHub gist, direct attachment here, or a different way to share them. Also, if there's anything specific you'd like us to trace further in the XmlMerge process, I'm happy to run |
|
I've merged this one @valadas @uzmannazari maybe we create a separate issue to document other misses? |
I did a
git bisectwhich pointed me to the commits in #6038 to rollup the sql scripts for v10. This made no sense to me since it's not really related to web.config and @uzmannazari pointed out in #6503 that a similar issue was caused by the LocalizationModule missing from the web.config. Also I could not reproduce the issue on upgrades. Then I thought since we have that v10 rollup, it uses the 10.00.00.config for the web.config xml merge scripts and up. Investigating the commit history of that file and comparing with 9.8.0 one I found that in #4251, a bugfix was done to ensure that the LocalizationModule is right after the UrlRewriteModule.This means that upon upgrades it would be in the right place but with clean installs, that would never run and it was also missing from the base web.config, thus making it not be there at all.
I was debating between putting this fix in the 10.00.00.config or just in the web.config I thought the web.config is fine as upon upgrades, the order would already have been fixed (as long as we document to upgrade to latest v9 before upgrading to v10). For clean installs it would just already be at the right place to start with.
Closes #6503