This is new in 5.3.5 or 5.3.4 (Didn’t happen in 5.3.3).
When the code fail to compile (example, you forgot a “;” somewhere), Unity closes all the custom Editor Window.
In our case, it’s a lot of different window, and it’s quite annoying.
Worse than that, it doesn’t just close EditorWindow instances, all assemblies are unloaded, resulting in every script showing up as unable to load. Any locked inspectors cause null references, making them impossible to unlock or even close.
If any EditorWindow is pinned as a tab somewhere, it closes and that area can not be reclaimed without restoring layouts or restarting Unity, either. Great for our editor tooling.
It’s a regression in 5.3.5, it did not happen in 5.3.4. I have reported it (800920) and I think it’s related to this:
Editor: Fix for core assemblies not being reloaded after encountering errors in user scripts. (750423)
If so, it’s not a very good fix, considering that’s a problem we’ve been working around with a simple reimport script since 4.6.
This is partly resolved in 5.3.5p2. It’s still a problem, in that an error still unloads assemblies while it did not use to, but only the assembly that fails to build is lost.
An error in Assembly-CSharp-Editor will still close all user EditorWindows and an error in Assembly-CSharp will still mark all scripts as unable to be loaded, neither of which ever happened until 5.3.5.
They thought they’ve fixed it in 5.3.5p2 referring to this issue:
However, the fix says it “fixes” the assembly dependencies, so I guess they allowed compilation of other assemblies to continue if there was an error in the ones compiled first. So now if there is a compile error in game scripts then editor will still continue with compiling the editor scripts. In their small test case that probably worked, but the thing is that such hack will never work in a real world project because there will be at least one editor script that needs some code from the game scripts.
The actual issue is that the editor doesn’t detect compile errors or it just ignores them. At the end of the compilation process the editor unloads previously compiled assemblies and tries to load the new ones, and some of them or all now don’t exist, so we end up with missing code for components, menu items, editor windows, custom inspectors, property drawers, and everything else that editor runs in edit mode.
I’ve reported the issue with more details, but the answer was that this is a duplicate of the issue linked above. I tried to explain that this is not what they thought exactly and I suggested to introduce a compile error in the editor script to see that assemblies are still unloading… I didn’t get reply on that, but I found a new issue logged here:
The description is very similar to what I tried to report except that there’s no mention that this is result of incorrectly unloaded assemblies after a compile error, so I guess they’ll still fix only the layout problem here and leave the recompile on error issue for next year eventually.
This whole thing is just ridiculous. I still have not received any response after the initial bug confirmation and it is breaking core engine functionality beyond repair! What on earth is going on there?
I guess they were busy with Unite Europe and their HackWeek.
There’s probably an easy fix, just to revert that ridiculous “fix” for reloading after a script error. What the hell, if there was a script error there should be no reloading at all! So annoying
Brilliant. Getting close to getting a full on repro for that issue and so far it seems to be related to this. If it is, whatever they changed seems increasingly like a very bad idea.
It turned out that the newly created issue in the issue tracker was actually derived from my bug report. That’s quite unfortunate because it still doesn’t describe the core of the reloading bug, but only one of its side effects - editor windows stop working on script compile errors and editor layout gets corrupted. I can imagine someone who gets assigned to fix that will argue that editor windows not working on compile errors is to be expected since the code didn’t compile and she will only fix the layout corruption issue. I replied with quite a long email describing the consequences if that happens - that will only hide the core of the bug even more that in worst case may result with project data corruption in Unity 5.3.5p2 and later versions! Running partially compiled code is extremely dangerous and that’s exactly what may happen after their bad “fix” for the first issue. I’ve also attached a tiny project to demonstrate how that fix doesn’t actually fix the issue, so hopefully they will revert that fix and reopen the issue.
That was a couple of days ago and I haven’t heard anything since then. I’ll let you know if something happens…
In meantime, you shouldn’t use 5.3.5p2 or a newer Unity version until they fix those bugs. Otherwise you put your project data under risk to get corrupted. Rolling back to 5.3.3 IMHO is the best thing you can do for now.
Yikes! This is a bad one. I have to revert to an older version of Unity until this is fixed.
I’ve voted for each of the two bug reports linked above, even though I understand that neither of them is really addressing the core issue. I hope Unity will get someone to really dig in and understand this soon!