I’ve upgraded my project version from 2022.1.16f1 to 2022.3.1f1 LTS and now my WebGL builld won’t complete.
It takes a long time during Linking buil.js and at the end it crashes.
Here’s what I’ve tried:
Optimizing for build speed and using development build, but the only difference is that it crashes faster.
Deleting the Library and Temp folders, no difference.
Upgrade to 2023…0b20 still same problem
Clean build, same problem
I’ve checked on another forum post about replacing the Emscript folder with the previous version but the game won’t build when I do it as well. I’ve only opened a new thread because I believe this issue is different than that one, [here ]( WebGL build "linking build.js (wasm)" takes forever page-3)people only complaint it takes forever to complete it, not that it crashes at the end.
Let me know if there’s any more information that can be helpful to find the problem, I need to deliver this project by Wednesday and if it wasn’t by this issue I would be ahead of schedule
First, make a blank project with a single blank scene and prove that it builds successfully.
If the blank project does NOT build, go fix your Unity installation or your other tools, such as Android SDK, NDK, JDK, etc. It may even be necessary to change to a different version of Unity3D. It is generally best to stay with LTS versions of Unity3D.
Until you can build a blank project to the target platform, don’t fiddle with anything else.
Once you can build a blank project, now bisect the problem by bringing over parts of your current project and building it one subsystem at a time, perhaps stubbing things out that might trigger compiler errors.
Most often things that prevent building are third-party libraries such as Firebase.
Once you identify the subsystem, go to the documentation for it and make sure you are doing it correctly.
It may also be helpful to work through a tutorial or two for whatever subsystem is making the build fail.
Android build not building:
Recently (circa July 2022) there have been reports of Unity’s installer failing to install the Android Tools.
ISSUES RELATED TO UPGRADING PROJECTS (eg, changing to a higher Unity version)
Upgrading to a later version of Unity is a one-way process. Any project that has been updated should NEVER be reverted to an earlier version of Unity because this is expressly not supported by Unity. Doing so exposes your project to internal inconsistencies and breakage that may actually be impossible to repair.
If you want to upgrade to a newer version of Unity, do not even consider it until you have placed your project fully under proper source control. This goes double or triple for non-LTS (Tech Stream) versions of Unity3D, which can be extremely unstable compared with LTS.
Once you have source-controlled your project then you may attempt a Unity upgrade. Immediately after any attempted upgrade you should try to view as much of your project as possible, with a mind to looking for broken animations or materials or any other scripting errors or runtime issues.
After an upgrade you should ALWAYS build to all targets you contemplate supporting: iOS and Android can be particularly finicky, and of course any third party libraries you use must also “play nice” with the new version of Unity. Since you didn’t write the third party library, it is up to you to vet it against the new version to make sure it still works.
If there are issues in your testing after upgrading Unity, ABANDON the upgrade, revert your project in source control and be back where you were pre-upgrade with the earlier version of Unity.
Obviously the less you test after the upgrade the more chance you will have of an undiscovered critical issue.
This risk of upgrading is entirely on you and must be considered whenever you contemplate a Unity version upgrade.
Do not upgrade “just for fun” or you may become very unhappy.
PROPERLY CONFIGURING AND USING ENTERPRISE SOURCE CONTROL
I’m sorry you’ve had this issue. Please consider using proper industrial-grade enterprise-qualified source control in order to guard and protect your hard-earned work.
Personally I use git (completely outside of Unity) because it is free and there are tons of tutorials out there to help you set it up as well as free places to host your repo (BitBucket, Github, Gitlab, etc.).
You can also push git repositories to other drives: thumb drives, USB drives, network drives, etc., effectively putting a complete copy of the repository there.
As far as configuring Unity to play nice with git, keep this in mind:
Generally the ONLY folders you should ever source control are:
Assets/
ProjectSettings/
Packages/
NEVER source control Library/ or Temp/ or Logs/
NEVER source control anything from Visual Studio (.vs, .csproj, none of that noise)
Setting git up with Unity (includes above .gitignore concepts):
It is only simple economics that you must expend as much effort into backing it up as you feel the work is worth in the first place. Digital storage is so unbelievably cheap today that you can buy gigabytes of flash drive storage for about the price of a cup of coffee. It’s simply ridiculous not to back up.
If you plan on joining the software industry, you will be required and expected to know how to use source control.
“Use source control or you will be really sad sooner or later.” - StarManta on the Unity3D forum boards
Thanks for your very complete feedback. I’ll make sure to source control and be much more careful upgrading unity version in the future. I really didn’t think that such close versions as 2022.1.16f1 to 2022.3.1f1 would be a problem, especially moving into an LTS version.
So, I’ve followed your advice about building an empty project and it works, but as I add more assets to this project the build time takes exponentially longer:
Empty project takes 107 seconds
Ultimate Inventory System takes 637 seconds
Bullet Pro + Quibli renderer is running for over 30 minutes already
And I haven’t even added my own scripts, meshes, musics…
The weird thing is that I’ve tried building the same project for Desktop and Android and it works perfectly, taking around 10 minutes to build.
I wonder if there’s any configuration under player settings that would help debugging and finding what causes the crash at the end of the build. I don’t care waiting for 2 hours to build the game, as long as it works at the end.
Did you increase the memory thingy for WebGL? It’s somewhere in the PlayerSettings, bottom section if I recall.
This almost feels like maybe you don’t have enough RAM and the system is thrashing… have you looked in the Task Mangler to see what kind of memory use and paging you are at?
After spending almost a week going nuts, trying everything I could find, I did what you said and created a new project. There I imported all the assets I had on my original project and the build still completed, took a long time, but it was successful at the end. So I went crazy and exported the entire Assets folder into a package and added to a new project, and, for my surprise, it built and the game was working!
So I took to the player settings to check each checkbox and every option I had on my previous project making sure it was like the new one and, after multiple builds, some worked, some not, I was finally able to individualize the problem, it was the checkbox:
When I disabled it my original project, it worked!!! FInally!
I don’t see why such a harmless checkbox would have caused this mess, who knows… Unity works in mysterious ways…
Way back in Unity3 or Unity4 they had an Enable Mobile Fog checkbox.
In Unity5 they removed it and just had the single Fog checkbox.
In only ONE of my projects the EnableMobileFog property was saved as OFF in ProjectSettings.asset
“WHY ISN’T MY FOG WORKING IN ONLY THIS GAME!?”
I made a new project, copied it over, and BOOM… it worked!
And then out came the diff and there it was.
Apparently that no-longer-editable field was still being listened to by the engine. Probably two different teams responsible for those two different areas. Sigh.