Bug (Case 1387523) Building player in batch mode is failed due to "A script reload is pending" error

Hi. I found that Unity 2022.1.0b1 is failed to build player in batch mode. In editor mode, no issue.

Here is error message:
Error building Player: A script reload is pending. Allow scripts to reload before building.

Same script works without any problems on Unity 2021.x.

Reported as Case 1387523.

 

It may be occurred by this:

This totally breaks automated build pipelines. Please revert it. Or add options for replacing scripting defines to BuildPlayerOption struct, not extra (add) only.

 

Thanks for detailed reply.

I tested your solution, MY_TEST_DEFINE=0, but it does not work on Unity 2021.2.7f1. It still defined on final build. Does it work only on Unity 2022.1b?

Edited : Adding extra symbol "XXX=0" does not work on both 2021.2.7 and 2022.1.0b2.

 

This is what we're doing in our build pipeline, is this not going to work anymore?

Code (CSharp):

1. PlayerSettings.SetScriptingDefineSymbolsForGroup(targetGroup, scriptingDefines);
2. BuildPipeline.BuildPlayer(buildPlayerOptions);

When you say "extraScriptingDefines", are these added on top of the existing defines in PlayerSettings? Is there a way to replace the current defines in PlayerSettings for a build?

 

What means this? Is it different to executing editor twice?

 

Yes. It already not work in Unity 2022.1b. So you can't build player with different (replaced or removed) build symbols from script. The only way is executing Unity twice, one for calling PlayerSettings.SetScriptingDefineSymbolsForGroup() and second for BuildPipeline.BuildPlayer() in CI pipeline.

In editor (without CI), there is no way for implementing simple build script. (sadly)

 

Thank you for the answer. This will break our build pipeline / build server then as well.

BuildPlayerOptions.extraScriptingDefines

looks like it could solve the problem for us, if it also allows to replace defines for a build and not only add new ones on top. Crossing fingers it's possible

 

Thank you for the reply.

Here are some thoughts: What if you rename

extraScriptingDefines

to just

scriptingDefines

but pre-polulate it with the current defines from Player Settings. With "current defines" I mean the defines that exist where the "extra" ones get added to.

This allows us to read what scripting defines exist, add new ones and remove existing from the list as we like. It could be easier to use as well, because we only have to deal with scriptingDefines instead of extraScriptingDefines and withoutScriptingDefines and whatever might come next.

What do you think?

 

We're also affected by this change unfortunately, preventing us from updating to 2022.1 (because we heavily rely on our automated build pipeline)...

If setting defines through the "extraScriptingDefines" really avoids this issue, having a way to remove defines could do the trick in our case. A "withoutScriptingDefines" API would be appreciated, although a general "scriptingDefines" property (as suggested by @Peter77 ) would be a bit cleaner IMO.

 

We have been executing the editor twice forever because Unity just breaks if we try to set settings and then build.

That is, of course, somewhat slower than just executing the editor once. It also means that we have to add build complexity to TeamCity instead of a C# build script. C# Is a lot easier to write than TeamCity settings!
So I would love to have a build script that survives domain reload, but I don't get what you mean by using a ScriptableSingleton? What we need to do is to have a way to:

- run some code that triggers a domain reload (and other reloads) as a side-effect of changing flags and other settings
- wait for the reload
- run more code.

I don't quite understand how a thing that stores editor state between reloads helps us do that? The editor state was never the problem, the problem is that running Unity in batch mode only executes a single static method, and that single static method can't keep running across domain reloads. Or am I missing something?

 

Ah, okay, replacing -quit with Application.Exit was the stage I was missing, thanks! Somewhat obvious now that you mention it

 

I haven't tried the recent betas yet, but does this issue still persist or has this restriction already been removed in the meantime?

 

2022.1.0b9 still has the issue.

 

Thanks for the update @Kichang-Kim !

Is there maybe an ETA about when the changes mentioned above (either a removal of the new restriction or a way to remove scripting defines) get implemented @jonas-echterhoff ? Will they make it into the tech stream release of 2022.1?

 

I recently implemented a build runner that survives domain reloads in my build framework Trimmer, for people who want a reference:
https://github.com/sttz/trimmer/blob/master/Editor/BuildRunner.cs

I was already using

extraScriptingDefines

and implemented the runner for switching the active build target between builds, due to various issues related to conditionally-compiled build code that would not run when the active and actual build targets don't match. But the principle could be adapted to change scripting defines in addition to changing the active build target.

You don't necessarily need to use

ScriptableSingleton

, any scriptable object instance can be used when you set the proper hide flags. The difficulty is that you cannot use types not supported by Unity's serialization, so any delegates are out. I worked around this by using an interface that can be implemented by other scriptable objects (that also need to be able to survive domain reloads).

 

I checked Unity 2022.1.0b15 and it still has the issue. Will this be fixed before releasing 2022.1.0f1?

@jonas-echterhoff

 

Shouldn’t you delay the release then? I mean why deliberately break everyone’s build servers by going live with such an issue? This can happen in betas but not "stable" versions. So weird as you already have a fix for it… just delay the release until the clear blockers are fixed or you will be wasting many people’s time.