I am currently working on a project that needs to download various unitypackages during the build process and import those afterwards. Running my editor scripts within my open unity instance works without a problem, but once I run an automated build with jenkins, using the Unity cli (batchmode, quit and executeMethdo) the AssetDatabase.ImportPackage method does not work anymore.
The Editor simply quits and the Asset-Pack ist not imported!
The AssetDatabase is off-limits during certain callbacks. One of these is a static ctor or an InitializeOnLoadMethod. I assume it’s in one of these places or the static method that we can call from the command line.
In those cases the fix is as simple as wrapping your code in delayCall:
EditorApplication.delayCall += () =>
{
// your import code here
};
No need to unsubscribe, the delayCall callback reference is cleared every time it ran.
However, I am still facing the same issue as the Editor instantly quits after calling the method.
PS: The Unitypackage contains spites, prefabs, scripts etc.
If it still quits, check the editor.log for details. Perhaps it works until it runs into a specific package? If so you should investigate that package further.
Also depending on other code, perhaps it helps to wrap it into delayCall twice, eg delay the delayCall that runs the actual code.
I wouldn’t download the .unitypackage files to the Assets folder. They don’t belong there, they should be located somewhere outside the Assets path to avoid Unity registering them as “assets” and adding them to the AssetDatabase for no reason.
No matter if I wrap the ImportAllModules method into another EditorApplication.delayCall or not, it does not properly import the package. The packages are fine and are now also stored in the workspace directory rather than within the Assets folder.
What about editor.log? Is it crashing after the first import, or with a specific one?
Do any of these packages add scripts? If so, check if they have static ctors or InitializeOnLoad(Method) and check if any of these could fail for some reason (eg using a path that doesn’t exist on the build machine). You may want to add logging to those methods to see how many of these run.