Hello Kristoffer,
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 1.0.0.0 which is indeed lower than 2.4.0.4. 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 3.0.0.0 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.
Hi Mark,
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?
/Kristoffer
I managed to find the problem with 58 so that is gone now but the initialization still fails. Any more suggestions?
Hi!
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?
/Kristoffer
Hi Kristoffer,
This still sounds like the model version for your content items within the database that you're trying to upgrade is 2.4.0.4 while your new CMS build is at 1.0.0.0 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 2.4.0.4. 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 1.0.0.0. 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 2.4.0.4 version of StandardPage and that the new definition is 1.0.0.0 ... a backwards change, which it will reject.
The new database would work because it does not have v2.4.0.4 of your previously created content types.
Thanks!
I found AssemblyInfo.cs in two projects containing 2.4.0.4, obvioulsy you can still use AssemblyInfo. I changed to 3.0.0.0 and then everything worked just fine.
Thanks for the guidance Mark!
/Kristoffer
Hi!
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?
Thanks!
/Kristoffer