I've been trying to upgrade a site for a customer recently, but after doing the upgrade to 7.5, the site is not running properly. I can log in and use edit/admin mode, but no pages are being rendered.
I get the following error:
Dynamic Data Store 7.0.859.16 can only be used with database version 6207, current version is 7000. Make sure both database and assemblies are upgraded correctly.
The upgrade was done with the Deployment center, and I've updated everything that I can think of in NuGet.
What are the versions of the assemblies in your bin folder?
Are your web.config assemblies referring to correct versions?
Everything seems to be 188.8.131.52 or 184.108.40.206 except Search (220.127.116.11) and EPiServer.Trace/Episerver.CMO (7.5.446.0). And also I have a reference to EPiServer.Packaging on version 18.104.22.168.
And as far as I can tell, the versions are the same in both the bin-folder and the web.config.
I believe you have to update the database schema, see "Applying database transforms" herehttp://world.episerver.com/Documentation/Items/Developers-Guide/EPiServer-CMS/75/Deployment/Updating-EPiServer-via-NuGet/
I did that earlier Fredrik, but I tried running it again today without sucess. The update runs, but the error remains. From the error message itself I would guess that the database update was succesful, but something regarding the Dynamic Data Store has not been updated (since DDS seems to think it's of version 7.0.859.16)
I had the exact same error yesterday and in my case I had old assemblies left in my bin so it seems that you have correct db version but somewhere a reference to an old assembly. I would start with checking the modulesbin folder, are all assemblies there correct version if you compare with an 7.5 alloy site? Also I had old references from temp files, so also try to delete everything in that folder. And if you unload and edit the project file, are all assembly version correct in the project file?
Yeah I think you're right, there is probably some old assemblies somewhere that are being loaded.
The modulesbin folder only contains EPiServer.Cms.Shell.UI.dll, EPiServer.Shell.UI.dll and NuGet.Core.dll. Both EPiServer dlls are the right versions (7.11). I can't install the alloy site right now, but I will try to check that during the weekend.
What temp folder do you mean?
I checked the project file after unloading it, and it has all the right (and only the right) assembly versions.
I've done a lot of upgrades lately, and had a lot of issues with old temp assemblies was loaded and causing issues, so try to delete everything you got for example here:
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files
Just make sure it is the right framework and .net version. Also just doublecheck the references in the project so they are not loading anything from the GAC that is incorrect versions.
Btw, don't you have episerver.shell.ui in the modulesbin folder? That one was always wrong version, don't know why but I had to copy the correct version from the Alloy site for every upgrade, even though I had updated all the add-ons.
I tried deleting everything from the Temporary ASP.NET Files, but unfortunately with no luck.
I don't have any references to the GAC in the project (and I even removed all dlls from the GAC for version 7.0.859.16), so nothing should be loaded from there.
I do have the EPiServer.Shell.UI in the modulesbin folder, but it is the right version.
In so case I can't think of anywhere else an assembly could hide. You can run the site in admin mode and verified that it is running on 7.5? But no pages is rendered? Where do u get the error message? Only when trying to reach for example startpage, but not in admin mode? Or in firebug?
Admin mode is running (and it is running 7.5), and I can login to the site. In "edit mode" I see the top menu and all the standard EPi-stuff, but no pages (the page part of the edit mode is just a YoD). The page tree is working and I can see the properties if I chose the "old time" editing style. When browsing the site, no pages work.
The issue seems to have been resolved by removing all CMO and Trace-assemblies from the project, and all config sections regarding CMO/Trace (which is fine, we don't really use that functionality anyway)