rvaishnav This sounds as if something is not right with your spine-unity installation. Could you please try removing the spine-unity runtime again and re-installing it?

Apart from that, if you have just upgraded from 3.8 to 4.0, we highly recommend to updatefrom 4.0 to 4.1 right away, to receive the many updates and bugfixes that have been published in the meantime.

Harald we have a lot of files to update, and updating the skeletons+textures again is out of scope for this release, so if possible we'd like to figure out of we can fix this build.

We will try to re-import spine , is it possible for us to tell spine to disable all GUI icons? Because on the old version they seemed to be required when we were doing builds, we had to whitelist them into the final output even tho they were just scene helpers not meant for publishing?

lucky Harald we have a lot of files to update, and updating the skeletons+textures again is out of scope for this release, so if possible we'd like to figure out of we can fix this build.

In general you could have upgraded the Spine project files from 3.8 straight to 4.1 and saved the intermediate step. Also, if you have many projects, we highly suggest automating exporting your project files using the Spine command line interface as described here. For example, we use this script to export all the Spine example projects and to create texture atlases: export.sh.

lucky We will try to re-import spine , is it possible for us to tell spine to disable all GUI icons? Because on the old version they seemed to be required when we were doing builds, we had to whitelist them into the final output even tho they were just scene helpers not meant for publishing?

You could easily tell the spine-unity runtime by changing the provided source code at your quoted line by returning Texture2D.whiteTexture or null if loading the icon asset fails:

// note: code below is untested.
static Texture2D LoadIcon (string filename) {
    var icon = AssetDatabase.LoadMainAssetAtPath(SpineEditorUtilities.editorGUIPath + "/" + filename);
    return icon == null ? Texture2D.whiteTexture : (Texture2D)icon;
}

Nevertheless, it's of course not desired that editor icons would be required during the build or in the built executable.

Because on the old version they seemed to be required when we were doing builds, we had to whitelist them into the final output

Could you describe what exactly you did as "whitelist them into the final output"? Also, how did you exclude them from the build, which triggers the build errors? Did you delete the icons entirely?

Harald In general you could have upgraded the Spine project files from 3.8 straight to 4.1 and saved the intermediate step.

We tend to use the older version typically for stability and so far with spine it has been great and we had no issues with 3.8 until upgrading unity so didn't see the benefits of updating to too new of a version unless necesary. But yes we will eventually upgrade to 4.1 , 4.2 etc.

Also, if you have many projects, we highly suggest automating exporting your project files using the Spine command line interface as described here. For example, we use this script to export all the Spine example projects and to create texture atlases: export.sh.

Yes we were looking at that script, but we have individual spine export settings based around different things such as some texture scaling on export is smaller than others, some use premultiply alpha some do not, some use single skeleton for sprite sheet some don't. So wanted to go the safe route to double check the files on exporting, unless of course we can use the commandline to convert a 3.8 export to 4.1 , instead of going trough spine and keeping the settings and texture sheets themselves 1:1. If there is a way to update just the binary let me know thank you.

You could easily tell the spine-unity runtime by changing the provided source code at your quoted line by returning Texture2D.whiteTexture or null if loading the icon asset fails:

That's true we could theoretically update the source code, we'll look into that!

Could you describe what exactly you did as "whitelist them into the final output"? Also, how did you exclude them from the build, which triggers the build errors? Did you delete the icons entirely?

We have scripts to make sure we export only what we need on build, so we only give users specific dlcs , that we don't have too big of an export etc. Some of the scripts check for lose images, called by scripts , which need to be assigned to a specific dlc otherwise we can't build the game. Or of course they can be added to the baseline export so its available to all the dlcs. So we applied a baseline setting to all the GUI icons because some of the spine scripts seem to be requiring them to run on build. We have not deleted icons, we only added an extra sprite sheet for them because they were mostly non power of two, just to keep our export script happy because it also requires our images to either be power of 2 or in a sprite sheet.
But yeah that was the long explanation.

Thanks for your help , we'll investigate further.

lucky Yes we were looking at that script, but we have individual spine export settings based around different things such as some texture scaling on export is smaller than others, some use premultiply alpha some do not, some use single skeleton for sprite sheet some don't.

You can use a specific pack.json config file with the respective settings for each skeleton export. A pack.json file can be created using Spine by clicking on the Save button at the bottom of the Texture Packer Settings dialog.

So wanted to go the safe route to double check the files on exporting

You could also check the files just as well after exporting them via the command line as exporting via the GUI.

unless of course we can use the commandline to convert a 3.8 export to 4.1
If there is a way to update just the binary let me know thank you.

While you could automate that via scripting, it's not recommended at all, and you might always lose data along the way. The .spine project file should always be kept, and should be the main source for all exports.

instead of going trough spine and keeping the settings and texture sheets themselves 1:1.

The Spine command line interface also starts Spine behind the scenes and performs the respective export (or import) tasks, just in an automated way.

We have scripts to make sure we export only what we need on build, so we only give users specific dlcs , that we don't have too big of an export etc.

Thanks for the detailed explanation. First I thought perhaps your build automation scripts are also calling or triggering Spine Editor methods, which indirectly then throw the respective exception, but the stack trace only shows EditorApplication:Internal_CallDelayFunctions as origin.

Unfortunately we could not reproduce this issue when deleting icon assets and performing a build thereafter. If you can reproduce this issue with a minimal Unity project, we would be happy to know what causes this issue and to fix it. Still if we don't discover why, we will add a the aforementioned null-check officially, if that resolves the issue on your end.