Since you've migrated from CMS 11 to CMS 12, you won't have an AssemblyInfo.cs for your projects anymore that describe the version of the application which is used for the content model for your content types. The default will essentially be 126.96.36.199 which is indeed lower than 188.8.131.52. You'll need to make sure the version information is directly within the csproj now.
<PropertyGroup> <TargetFramework>net6.0</TargetFramework> <AssemblyVersion>0.6.0.0</AssemblyVersion> </PropertyGroup>
If you apply a version of 184.108.40.206 to the csproj files does it solve your issue?
I'd make sure that you have a separate development database for CMS 12 just in case you have to support the CMS 11 version during the conversion process.
Thanks for the reply. It says that version in database i 58.0. Where should I find the <AssemblyVersion>? I cannot find anything in my .proj files?
I managed to find the problem with 58 so that is gone now but the initialization still fails. Any more suggestions?
I can confirm that I can access the edit mode if I connect the database to an empty project using the dotnet new epi-cms-empty command.
So there is something in our solution I guess?
During the upgrade we have moved all page types and custom properties to new namespaces, could that have something to do with it?
This still sounds like the model version for your content items within the database that you're trying to upgrade is 220.127.116.11 while your new CMS build is at 18.104.22.168 which can only be resolved by updating the version of your assemblies.
Lets say you have a content type of StandardPage: when your build pipeline versioned your dlls or the AssemblyInfo.cs of your CMS 11 project had a version of 22.214.171.124. When creating or updating those content types, the version number that was applied to your dlls at that time is recorded into the Optimizely CMS database alongside the new configuration of the content type.
As part of upgrading to CMS 12 that AssemblyInfo.cs no longer exists as it's not a .NET 5+ thing. So now your dll is effectively 126.96.36.199. When the application starts up and tries to migrate property or namespace changes for StandardPage, it will be checking the version numbers assigned to them. It will be understanding that the database has a 188.8.131.52 version of StandardPage and that the new definition is 184.108.40.206 ... a backwards change, which it will reject.
The new database would work because it does not have v220.127.116.11 of your previously created content types.
I found AssemblyInfo.cs in two projects containing 18.104.22.168, obvioulsy you can still use AssemblyInfo. I changed to 22.214.171.124 and then everything worked just fine.
Thanks for the guidance Mark!
I have upgraded from CMS 11 to CMS 12 but the project fails on startup:
I also find this in the windows log if that could have something to do with it:
Ideas what could be causing this? We have also moved page types from a Core project to Features/Pages/Standpage and so on. Could that be a problem?
We also moved some properties tagged with [PropertyDefinitionTypePlugIn] to a different namespace which gave error on startup since the definition TypeName has changed.
I updated the TypeName in the tblPropertyDefinitionType and then that error disapeared. Is that ok or could that cause a problem?