chore: fix #412 #622 iOS resolver reference when iOS module not installed

[StephenHodgson]

• fixes [BUG] Unable to resolve reference 'UnityEditor.iOS.Extensions.Xcode' on Windows #412
• fixes [Bug] IOSResolver.dll tries to load on Windows/Linux - causes error #622
• updated export_unity_package_config.json and separated Google.IOSResolver.* into its own PluginImporter section, adding defineConstraints key with UNITY_EDITOR and UNITY_IOS elements.
• lint export_unity_package_config.json with standard json lint, 2 spaces
• added defineConstraints to AssetConfiguration in export_unity_package.py
• added unit tests for defineConstraints in export_unity_package_test.py
• updated workflows to use latest version of checkout/setup actions

Fixes

Assembly 'Packages/com.google.external-dependency-manager/ExternalDependencyManager/Editor/1.2.183/Google.IOSResolver.dll' will not be loaded due to errors:
Unable to resolve reference 'UnityEditor.iOS.Extensions.Xcode'. Is the assembly missing or incompatible with the current platform?
Reference validation can be disabled in the Plugin Inspector.

Invalid when platform is not set to IOS or module not installed

Valid when platform is set to IOS

CC @a-maurice, @chkuang-g

[f1yingbanana]

This looks good, I'll try and get it reviewed :)

[a-maurice]

Thanks for sending this, and diving into the export_unity_package script! At a first glance it seems good, but I'll want to spend some time testing it with different install configurations to make sure it doesn't cause any issues, which might take a little bit of time. But I'll try to get to it when I can!

[StephenHodgson]

@a-maurice feel free to push any changes or remake this PR as needed :)

[Sairony]

Is it possible to get this change in some way without building locally from latest source? We have https://github.com/googlesamples/unity-jar-resolver.git?path=upm added as an dependency in unity per instructions, but this I presume just gets the latest release, which currently doesn't seem to contain this fix. Since the files lives inside the package folder using this method, which we very much prefer from having it live in the Assets/ folder, we can't modify served file locally to fix it manually. As such this issue is preventing any build from succeeding for us in Unity 6.

[StephenHodgson]

which we very much prefer from having it live in the Assets/ folder.

I disagree. We definitely don't want it assets folder. It properly belongs in packages since it is external. Downloaded as .unitypackage it makes sense to be in assets folder.

[Sairony]

which we very much prefer from having it live in the Assets/ folder.

I disagree. We definitely don't want it assets folder. It properly belongs in packages since it is external. Downloaded as .unitypackage it makes sense to be in assets folder.

That's what I'm saying, English isn't my first language but yes, I want all plugins out of the Asset folder, because we want to disable for example the google play plugin entirely for build targets where it isn't relevant, which is impossible if it's in the Assets folder.

[StephenHodgson]

That's what I'm saying, English isn't my first language but yes, I want all plugins out of the Asset folder, because we want to disable for example the google play plugin entirely for build targets where it isn't relevant, which is impossible if it's in the Assets folder.

Then just unzip the .tar packages and do local embed. But tbh the way it is currently setup is IMHO the best and correct way to package this type of asset. That isn't gonna ever change.