We just upgraded a large project from 2019 to 2020. This went mostly smoothly, except that Unity will absolutely not recognize one component, giving me the yellow prefab error saying the component isn’t valid, etc. After much experimentation I found that it works fine as long as I remove the component from its namespace. There’s nothing strange about the namespace, many other components use the same one. It also builds fine, and if I add syntax errors the compiler picks them up and complains about them (just wanted to check if it was being compiled at all). Other components that reference this type also compile without issue.
I haven’t seen this with any other components, but I am a bit nervous there are others hiding here. I’ve reimported several times without help.
Any thoughts on where to go to start diagnosing this? I looked in the editor log and couldn’t find anything. Are there other logs I could take a look at?
Anything special about that component, such as part of an asmdef?
What about if you right now made a fresh prefab using the component (in its proper namespace)… does that work?
If so you can open the good new prefab and the one that’s failing and look for the GUID of that Component, see if there’s something untoward about it.
As you probably already know based on your post above, here’s my standard knowledge-dump:
Some info about Missing script warnings, GUIDs, renaming GUIDs, etc:
EVERYTHING in Unity is connected to the above GUID. It is super-easy to inadvertently change it by renaming outside of Unity. Don’t do that. Instead:
close Visual Studio (important!)
rename the file(s) in Unity
in Unity do Assets → Open C# Project to reopen Visual Studio
now rename the actual classes, and MAKE SURE THE FILE NAMES DO NOT CHANGE!
If you are NOT using source control while you do this, renaming files is an EXTREMELY dangerous process. Use source control at all times so that you can trivially revert if you miss a critical step and damage your project.
The project is broken into assemblies to keep dependencies clean. But this component is in an assembly with a bunch of other components, and shares the namespace with those other components.
I even went so far as to rename this file with a “2” suffix in Unity then create a brand new MonoBehaviour with the same name. The new MonoBehaviour exhibited exactly the same symptoms! Even though it had a new GUID, etc. This is how I worked out that the namespace seems to be linked the underlying issue. The “2” version also worked fine, so the GUID wasn’t an issue (renaming in the editor ensures that the meta file + GUID follows it). The brand new MonoBehaviour with literally no fields also could not be added to a GameObject. So it really does seem to somehow be linked to this particular named class. One thing I haven’t tried is putting this class in a different namespace (instead of global)–mostly because I need to refactor all the places that reference it and I haven’t wanted to tackle that yet. It’s acting as though Unity can’t see this class in the assembly–but the compiler is processing it as I found when I injected syntax errors.
I’ll dig through the asmdefs to see if somehow I’ve inadvertently left this particular file out–but even then that should be a file issue and not a class name issue.
I’m also half expecting it to go away on its own–I’ll try adding the namespace back in after I’ve done some testing and run a build, etc.
My bigger concern is that this points to a deeper issue and that I’ll find many other components that are suddenly broken. This project is part of an SDK that we distribute so I really don’t want one of our clients to find this on our behalf.
Not sure what else to add… it sounds like you’re using great cross-check techniques (making the “2” class, trying to add fields, mixing and matching) and I assume at some point you will come across whatever bizarre little bit is tripping it up.
What about project-wide adding a “2” to the namespace itself? Then what if you re-create the original offending namespace and put only one class in there? etc.
In case anyone hits something similar, I found that if I removed a deprecated code block at the end of the file it was back to being recognized. The code was toggled off with an #if DEPRECATED flag and the #endif was just before the final bracket of the class. This didn’t cause any build errors, but somehow must have confused Unity’s parser or similar.