Connie Wooding (State of Florida) asked a question.
The database schema and Sitefinity version are different (8146 vs 8132), so it looks like the Sitefinity version needs to be updated to match the database schema version. I think installing the security patch messed us up. I found Internet articles about NuGet. We don't have a NuGet config file. How can this get fixed?
Simple webconfig tweak
https://www.sitefinitysteve.com/blog/avoid-version-errors-with-assembly-binding/
if the DB needs to actually be updated and not the file I believe you null out the version in the module table and on reload it’ll reinstall that module (won’t lose anything),
I do not have those 3 dependent assemblies. Where does the public token come from?
I guess I could just add them and say oldVersion="0.0.0.0-65535.65535.65535.65535" newVersion="14.4.8146"
In the DB, sf_module_version NULL out the version and leave the previous_version?
It's not specific to those 3, you can bind any dll up. USUALLY you get it when you have a project\dll that was built on against a previous version (like it had it as a reference) but now you've updated that DLL to a new version so it's trying to load the version it was built against... you have to just nudge it in the webconfig.
Can you share the error screen, that usually has all the details in it to use.
The article says The solution was remarkably simple:
Unfortunately, for me it is not simple. So I thought I would try the other routs. Since a couple of years ago I used the CLI, I thought I would try updating using it again. Dummy, dummy, me. I am trying to reinstall the CLI. Copying it soen and unzipping it has taken over 24 hours. The window says it will complete in another 6 hours. I thought that it would be good to have an updated version. I was wrong so now I have a bigger mess. I should have left well enough alone.
Going back to this method, in the DB, set the sf_module_version NULL out the version and leave the previous_version? Some of the modules have values, some current version and some NULLs.
Hi @Connie Wooding (State of Florida) ,
If I'm understanding, the database being pointed at in your web.config or data.config has a newer version than Telerik.Sitefinity.dll in your bin folder.
Can you tell us how the security patch was installed? The recommended way is to use Sitefinity CLI to upgrade versions, and this tool should manage assembly bindings for you. Here are a couple of links. I don't believe these work at the moment due to a Cloudflare issue, but these should help.
https://www.progress.com/blogs/convert-your-sitefinity-website-to-use-nuget-packages
https://www.progress.com/documentation/sitefinity-cms/upgrade-using-sitefinity-cli
I downloaded the Sitefinity CLI from GitHub to a local directory and then extracted the files. I don't remember exactly what all I tried. It was at a command window and not a nice click update procedure like we have in the NuGet Package Manager. It didn't find anything so I abandoned that. Can I try to get the CLI to go now that I have a botched up mess?
If the database has been updated, but you don't have the right DLLs, and the situation is not that someone else ran the upgrade and can just check in the changes, then I think running the CLI again is a good idea. There's a new patch you can apply: 14.4.8147.
- sf upgrade "(path-to-your-project)\SitefinityWebApp.sln" "14.4.8147"
It doesn't recognize sf. I remember a year ago doing a sf upgrade ... but do not remember the details of how I got that to go.
If your computer doesn't know what "sf" is, that means the folder where sf.exe lives is not in your path, which is the Windows environment variable that tells the operating system where to find executable files. In that case, you'll need to find the folder that contains sf.exe. For me, it's in D:\Apps\sf-cli-win-x86 1.1.0.69 because that is the random folder I put it in. This command would work for me, but you'll have to figure out what the folder is for you (or download a new copy :) )
- "D:\Apps\sf-cli-win-x86 1.1.0.69\sf.exe" upgrade "(path-to-your-project)\SitefinityWebApp.sln" "14.4.8147"
I found it. I installed it in 2022 so it i a bit old. When I tried to run it it was looking for framework 3.0.0 but found 8.0.16, 9.0,17 and 9.0.5. I am copying down a fresh copy of sf-cli-win-x86 files and will try it.
Resolution for future searchers. There are a couple of issues mentioned in the original post.
1) The database schema and Sitefinity version are different (8146 vs 8132)
If a Sitefinity upgrade is run locally, but a remote site or other developers use the same database, other users of the database can receive a message that says "Downgrade is not allowed". One option is to create a copy of the database that is used during the upgrade, so the other users of the database are not affected. A second option is to tell Sitefinity to ignore downgrade exceptions in the short time until the updated code is published to all users of a database. We do this by adding
"SF_IgnoreDowngradeExceptions=True" to the connection string for all users of the database.
2) How to resolve assembly binding errors?
Connie updated her site to 14.4.8147 using the Sitefinity CLI
When running the site, it had an error about System.Numerics.Vectors.
Reviewing web.config, we found an assembly binding that was forcing the site to look for and use version 4.1.5.
Looking at the reference in the visual studio solution explorer, we see that this version of Sitefinity comes with System.Numerics.Vectors version 4.1.4.
Updating the assembly binding in web.config to use version 4.1.4 fixed the problem.