SUB docked window fails to load from saved layout

[nickfourtimes]

A very low-priority papercut. I've saved SuperUnityBuild as part of my layout for my current project; however, every time I load the layout, I get the following error:

The layout "/Users/nick/Library/Preferences/Unity/Editor-5.x/Layouts/default/MY_PROJECT.wlt" could not be fully loaded, this can happen when the layout contains EditorWindows not available in this project.
UnityEditor.WindowLayout/<>c__DisplayClass43_0:b__2 () (at /Users/bokken/build/output/unity/unity/Editor/Mono/GUI/WindowLayout.cs:595)

Just confused as to why this occurs, given that SUB is part of my project.

[nickfourtimes]

Oh, interestingly, this seems to happen on macOS specifically, and not on Windows. I'll keep looking into it.

[robinnorth]

I believe I have seen it happen on Windows occasionally, but have never got to the bottom of what triggers it. Thanks for looking into it some more!

[nickfourtimes]

No idea if this has anything to do with it, but I'm also noticing that whenever I open the SUB window for the first time in an editor session (because it fails to load from my saved layout), my SuperUnityBuildSettings.asset is created anew, overwriting any configuration I'd already set up.

I've traced that to the following line in BaseSettings.CreateAsset<T>():

buildtool/Editor/Build/Settings/BaseSettings.cs

Line 22 in 4b82f76

T instance = AssetDatabase.LoadAssetAtPath<T>(assetPath) as T;

It looks like, even though I can confirm that assetPath exists, and is a BuildSettings object, AssetDatabase.LoadAssetAtPath<T>() doesn't recognise it, and returns null; thus instance is null, and we (re)create the BuildSettings file in place.

I want to say I've seen cases where LoadAssetAtPath<T>(path) and LoadAssetAtPath(path, typeof(T)) as T have returned different results (!!), but I've tried both here and haven't been able to prevent the overwriting.

Again, not sure if that's related to this original issue or if I should spin it out into a new one...

[robinnorth]

I have definitely seen my SuperUnityBuildSettings.asset get overwritten like that during lengthy asset imports, which makes me think the point at which LoadAssetAtPath<T>(path) is called can sometimes be too early for the asset database to return the instance, so perhaps worth spinning out into a new issue?

[nickfourtimes]

Alrighty, I've spun that issue off separately, and we can keep focusing on the saved layouts issue here 🙏