I’m trying to automatically update the unity version and the update all packages to their latest version for that new unity version through an automated step. However, there are packages that are not compatible anymore when updating unity. For example com.unity.render-pipelines.universal@12.1.7 is the latest version for 2021.3.15f1, but is incompatible with 2021.3.16f1 (which requires com.unity.render-pipelines.universal@12.1.8). The problem is, that I get the following error when starting unity with 2021.3.16f1:
Error message
When I run Unity normally, I can just say continue and then run my update script. However, when running in batchmode, I didn’t find a way to ignore the error and still be able to use UPM afterwards to update the packages. I tried adding ‑ignorecompilererrors, but this doesn’t ignore that problem. Adding -noUpm does get rid of the error, but then I can’t use UPM afterwards to update packages. Is there any other parameter I can pass, to silently ignore that error (as if I would click continue in normal mode)? Or is there a feasible way to update the packages outside of the editor before starting it with the new version? If there is no way, it would be great to have some new argument (such as -ignoreUpmErrors) to be able to still run unity in batchmode, so I can fix the problem in the editor.
Edit: btw, this is the error I’m getting in batchmode:
[Package Manager] Done resolving packages in 19.50s seconds
An error occurred while resolving packages:
Project has invalid dependencies:
com.unity.render-pipelines.universal: Package [com.unity.render-pipelines.universal@12.1.7] cannot be found
A re-import of the project may be required to fix the issue or a manual modification of /github/workspace/Packages/manifest.json file.
/home/bokken/build/output/unity/unity/External/baselib/builds/Include/C/Internal/Baselib_Semaphore_FutexBased.inl.h(151): Assertion failed (count >= 0) - Destruction is not allowed when there are still threads waiting on the semaphore.
Trace/breakpoint trap (core dumped)
Build failed, with exit code 133
I’m sorry you’re running into this issue. Do you have "disableProjectUpdate": true in your project manifest by chance? When upgrading the Editor, the Package Manager updater should normally take care of bumping dependencies in the project manifest like this prior to resolving dependencies, avoiding this error specifically.
thanks a lot for your answer. Nope, sadly I don’t have disableProjectUpdate enabled (interesting feature though). Here is the manifest: https://github.com/JohannesDeml/UnityWebGL-LoadingTest/blob/test-upgrade-unity/Packages/manifest.json
You can also reproduce the problem by checking out the repo on branch /test-upgrade-unity and then try to open the project with version 2021.3.16f1. Maybe there is a problem for the upgrade logic in the URP package? Should I create an issue for you, or is this post enough for you to track the problem?
Small side note: If it should upgrade automatically, the problem exists for both normal start as well as batch mode.
The upgrade logic I was referring to is not specific to given packages, it’s handled globally by the Package Manager during project initialization.
I see in your repo that the ProjectSettings/ProjectVersion.txt file has m_EditorVersion: 2021.3.16f1 but your project manifest has com.unity.render-pipelines.universal@12.1.7. That would tell the Package Manager to skip the update process in 2021.3.16f1 since the ProjectVersion.txt version already matches the Editor version. Did you by any chance commit the ProjectVersion.txt file after opening the project in 2021.3.16f1 without updating the Packages/manifest.json change? (This is what Update to 2021.3.16f1 · JohannesDeml/UnityWebGL-LoadingTest@124d50c · GitHub suggests.)
Thanks a lot for digging deeper! That makes sense, I upgraded Unity on a non-urp brach, which I then merged into the urp branch (In the repo I’m comparing build sizes for urp vs builtin render pipeline on WebGL). Is there a possibility to trigger this re-evaluation manually? Otherwise I guess I need to first upgrade on the urp branch before merging in changes from the master branch (or not upgrading unity versions on the master branch).
Unfortunately not, but a simple way to solve this would be to revert the change in ProjectVersion.txt in that branch to force it to run the upgrade logic the next time it’s opened in 2021.3.16f1.
It’s kind of a blind spot in the implementation, but I don’t really see how else we could do this, it’s fundamentally a problem with branching in general. It’s an indirect conflict in concurrent edits, not unlike, say, when renaming a class in one branch, and adding a derived class with the original base class name in another branch: when the rename branch is merged into the branch with the derived class, it will not result in a Git conflict, but the code will no longer compile because the derived class would still use the original base class name.
One way to avoid this is to perform the upgrade in each branch separately. For instance, when you’re about to merge one branch into another branch, if you see ProjectVersion.txt changes, that could be a red flag that reminds you to first upgrade the target branch to the same version. In your case, you are free to upgrade Unity versions on the master branch, but when you want to update your URP branch with the latest master, make sure you first upgrade the URP branch on its own so that they are on the same Unity version.
Totally makes sense, my use case is a bit special with different packages on different branches, but I guess I will just work on my setup (by having he master branch just for code updates and all other branches are responsible on their own to do the updates. Another solution would be to make sure the update is started from the correct version as you suggested, but this seems a bit counter intuitive to revert already done changes on another branch.
This was very insightful, thanks a lot for the information (which I didn’t find anywhere before).
Good afternoon, I’m having the same error with a few caveats. I’m making a “new” project from scratch (2021.3.14.F1 iirc), without the HUB, on a non-network computer, that I cannot update as it is locked down. I’m getting the same unagle to add package URP install error @12.1.7. It is looking for Burst 1.7.3, but my Unity install has Burst 1.6.6. I do not have permissions to update the manifest.json files or anything Program Files to change anything.
I’m projected to get a new computer with updated Unity… but told in 2+ months. Is there something I can do to (change a config file, project file, etc?) to fake it and allow it to install? I’m needing URP and the project can’t afford to wait for the new computer.
