I have noticed some errors coming up in the web console of runing unity webgl projects that could be pointed out before hand and are a little surprising, e.g.:
A script behaviour (probably UIStyle?) has a different serialization layout when loading. (Read 32 bytes but expected 288 bytes) UnityLoader.js:137:322
Did you #ifdef UNITY_EDITOR a section of your serialized properties in any of your scripts?
I also see “Could not produce class with ID XX - This could be caused by a class being stripped from the build even though it is needed. Try disabling ‘Strip Engine Code’ in Player Settings.”
which is a bit concerning but I can reduce stripping - unfortunately that adds 1.4mb of data
I’d wager the error is a side-effect from the code that is being stripped, which is probably the root issue. Rather than disabling stripping, you can control the stripping somewhat more finely. There’s a couple of ways about this.
The easiest way, if it’s a managed class being stripped (generally due to using Reflection), is to simply use the [Preserve] attribute on the class (assuming you’re using Unity 2017.1 or newer). However by the sounds of it you’re most likely dealing with something native being stripped if you’re getting errors like that.
The way to prevent other assemblies from being stripped is using a link.xml file which you can use to preserve certain namespaces or entire assemblies. Fortunately this is explained in the documentation pretty well.
The quick hacky way I’ve seen a few people use if they load things like terrains and other bits via asset bundles, is they have an empty scene with all the types of components that would otherwise get stripped, and just ensure it is included with the build. It works but its a bit yucky.
This page is helpful for figuring out the class ID that you’re getting in your error to see what is being stripped:
Thanks, those references are very helpful (though quite why the Avatar class is causing me an issue when I don’t use animation is interesting - but I think an assetbundle issue)
Just ran into exactly this error when switching platform to WebGL: Case 1122301
Update: Tested it with link.xml to preserve everything in the assembly - same error.