Scripts from local packages remain unrecognized by Unity Editor after upgrade to Unity 6

Problem:

In our team, while working with our own local packages that we share amongst two Unity projects, we upgraded both Unity projects from Version 2022.3.47f1 to 6000.0.34f1. We are now encountering issues in one of the Unity projects.

Attached MonoBehaviour scripts from some of our own local packages show up missing in the scene:

For MonoBehaviour scripts stored in the Assets folder, there is no problem. But for 4 out of 5 of our own local packages the problem exists. The only identifiable differences in the unaffected package compared to the affected packages is that it doesn’t have any assembly definition references in the assembly definition asset.

Furthermore, creating a new MonoBehaviour Script inside one of the four affected packages and dragging it onto a game object in the scene will result in an error popup with the message: “Can’t add script component ‘NewMonoBehaviourScript’ because the script class cannot be found. Make sure that there are no compile errors and that the file name and class name match.”

We don’t have any compile errors for any of the packages and no warnings associated with the problem.

Failed attempts to solve the problem:

  • reimporting the scripts or deleting the Library, obj and Temp folder of the project and restarting Unity Editor
  • deleting the packages or upm cache in AppData\Local\Unity\cache
  • reimporting the affected packages with the package manager
  • upgrading to Unity 6000.0.36f1
  • deleting meta files of affected scripts
  • regenerating visual studio solution files

Further observations:

  • Play Mode can be entered but the components turn out to have a value of null when retrieving them via GetComponent()
  • Calling CompilationPipeline.GetAssemblies() from an EditorWindow class returns amongst others all five of our packages with dlls located inside Library\ScriptAssemblies
  • Looking at scripts in the project window the inspector’s debug mode shows differences between the unaffected package and the affected packages: Class Name, Namespace and Assembly Name are not displayed for any scripts (also non-MonoBehaviour) of the affected packages.
  • Adding the scripts as components via gameObject.AddComponent() at runtime from inside the Start() method of another MonoBehaviour script works. The components are not null and show the correct class name when logging them to the console.
  • Using the same packages in another 6000.0.34f1 Unity projects works fine without the problem arising

Are these local packages located under <root>/Packages/<the.package>?

This sounds like the same case I had encountered, but it was specific to Multiplayer Playmode where any MonoBehaviour in a embedded package was listed as “Missing Script” in virtual players. It worked when I moved the package to Assets or added it “from disk”. Your issue sounds like it could be related.

Try creating an embedded package in a new project and add a MonoBehaviour to it to see if this issue exists in a vanilla project. If so, you should report it (Help - Report a bug).

As a workaround, if possible and actually the more suitable workflow, would be to remove embedded packages and rather pull them from their own repository in a directory next to the project’s directory. Then “add from disk” this new package repository, and after you did this with all packages, edit the manifest.json. Change the package paths so that they are relative to the project. Then every team member needs to pull the package repositories to the same relative location.

The way you described it is how we are handling it at the moment. So they are not located in the Packages folder of one project, as we need to share them amongst two Unity Projects and keep them updated with source control.

Creating a new package and adding it to a new project doesn’t reproduce the problem. Even adding one of our affected packages to a new project works fine. It seems that only this one Unity project is corrupted.

I wouldn’t say it’s corrupted, but rather affected. :wink:

At least this points to something within the project as the culprit, be it an editor script, a package, or a setting.

You could try stripping down a package that has this problem down to just leaving the MonoBehaviour in it, to see if this somehow fixes the problem. Also removing asmdef dependencies, although I doubt these would affect the issue.

Although … maybe the asmdef is set up incorrectly? I could imagine that the package asmdef may exclude the Editor platform, or the MonoBehaviour was created under an asmdef that’s flagged editor-only.

Just to be sure, both class and filename were named NewMonoBehaviourScript(.cs)? If the name mismatches, the MonoBehaviour is nonfunctional.

Does adding the script also create a corresponding NewMonoBehaviourScript.cs.meta file?

What happens if you add a new empty package to the existing project, does it also exhibit the behaviour? If not, you could try and add things from other packages to it, basically rebuilding the package step by step to see at which point it starts to falter.

Thank you for your answer!

You are right affected, would have been a better choice of a word :slight_smile:

We tried stripping as well, but that couldn’t solve our problem either.

I checked the .asmdef settings many times and I think they weren’t the cause of the problem either.

Name mismatches were not the problem, I guess. Meta Files were created, too.

In the end we could solve the problem by recreating the Unity Project from scratch and renaming the affected package. Like this we don’t have any problems anymore at the moment.