Did you build the project and run the /install wizard after you upgraded the nuget package? Usualy when you update the nuget, build the website and try to visit the backend the install wizard will automatically start.
If the wizard starts, make user your database user has sufficient rights to change the database schema.
What i did was upgrade via NuGet which gave me an error, so i went in and copied the Umbraco and Bin folder from the zip release, and replaced everything, and then i deleted my project dll file, and then i could upgrade, after that it was possible to build my project! :)
I've done some tests, I think uSync is a red herring here.
uSync with ImportAtStartup set, will work between upgrades of Umbraco (including across the 8.9. v8.10 property change boundary). Looking at error in the original post. it actually originates in a custom composer (RegisterCustomRouteComponent in CustomRouteComposer.cs).
It is likely that this composer does not have runtime restriction on it (e.g it doesn't have [RuntimeLevel(MinLevel = RuntimeLevel.Run)]) which means umbraco will trigger the compose (and the resulting component) when ever it boots up, including during an upgrade.
Without extra attributes you can't guarantee the order the composers are loaded up by Umbraco, my guess is your custom composer was running before some of the core code got to do its migrations.
Removing uSync will have removed the uSync composers and this will have altered the order in which all your composers loaded. and then the migrations had a chance to run before your custom code. this gives the appearence it was uSync causing the issue, but i think it merely changed the execution order of existing code and that solved the issue.
I would say you need to add the runtime attribute to your custom code and then this should guard against upgrades causing you issues in the future.
So something like - will ensure it doesn't run during the upgrade.
[RuntimeLevel(MinLevel = RuntimeLevel.Run)]
public class CustomRouteComposer : IUserComposer {
// composer code in here ...
}
Update Umbraco 8.9.1 to 8.10.0 (or higher) gives a error after starting the application
Hi,
I have updated Umbraco van 8.9.1 to 8.10.0 (also to 8.12.1). After updating the nuget packages and starting the application i get an error:
I see the column 'LabelOnTop' is missing in the table 'cmsPropertyType', can i add this manually?
Has anyone a solution for this?
Best regards, Ruben
Hi Ruben,
Did you build the project and run the /install wizard after you upgraded the nuget package? Usualy when you update the nuget, build the website and try to visit the backend the install wizard will automatically start.
If the wizard starts, make user your database user has sufficient rights to change the database schema.
Erik
Hi Erik,
I have updated all the packages and projects in the solution.
Umbraco throws the error directly after running the application. Before normally umbraco gives the 'update page'
Hi Ruben,
Thats strange, perhaps this solution will work for you: https://our.umbraco.com/forum/using-umbraco-and-getting-started/101716-cant-upgrade-to-v86
Hi,
I have tried that solution, but it doesn't work.
Is it possible to run the sql script manually? Maybe i will get the right columns in the tables?
We use Usync in our projects. I have uninstalled the nuget packages voor Usync.
Then the installer will load correctly!
I've done some tests, I think uSync is a red herring here.
uSync with
ImportAtStartupset, will work between upgrades of Umbraco (including across the 8.9. v8.10 property change boundary). Looking at error in the original post. it actually originates in a custom composer (RegisterCustomRouteComponent in CustomRouteComposer.cs).It is likely that this composer does not have runtime restriction on it (e.g it doesn't have
[RuntimeLevel(MinLevel = RuntimeLevel.Run)]) which means umbraco will trigger the compose (and the resulting component) when ever it boots up, including during an upgrade.Without extra attributes you can't guarantee the order the composers are loaded up by Umbraco, my guess is your custom composer was running before some of the core code got to do its migrations. Removing uSync will have removed the uSync composers and this will have altered the order in which all your composers loaded. and then the migrations had a chance to run before your custom code. this gives the appearence it was uSync causing the issue, but i think it merely changed the execution order of existing code and that solved the issue.
I would say you need to add the runtime attribute to your custom code and then this should guard against upgrades causing you issues in the future.
So something like - will ensure it doesn't run during the upgrade.
Hi Ruben,
Good to read that you found the solution!
is working on a reply...