prefabs and other game object get missing scripts to scripts in a package

Hello,
We are currently in the midst of moving our code base out of Assets into packages (to make it more modular) and I've encountered a peculiar problem. I moved 4 scripts from a subfolder in Assets into the package and then re-imported the package back into the project. Up until these 4 scripts, everything went smoothly with no errors. But for these four which are on objects and prefabs in the main scene all the connection to them had been broken (their components have "missing script"). The first time I thought I did something wrong and manually fixed the 500+ broken references. But now after updating the package (from disk, I still don't push it to git) all the references are broken again but the scripts themselves have not been changed or moved and the meta files (and guids) remain the same as well.

Why is that? All the files under the Assets folder that we created have no asmdef but the package I make have one. Could this be it? Also in that package, these 4 files are in the same folder as the asmdef file and not in a sub-folder of it. Could this be it?

What can I do when the next time I update the package it won't severe all these connections again?

 

Hi @manu73
Indeed I've moved them internally within the Unity editor. It was done in version 2018.3.9 or 2018.3.8 I don't remember. Switching to 2018.3.11 didn't resolve it either.

 

Also, I wonder if it has anything to do with warnings in the console that look like this:

warning CS0105: The using directive for 'common.views' appeared previously in this namespace

I want to re-illustrate my workflow for clarity sake.

99% of our scripts are arranged in namespaces (the ones that aren't are by mistake or in a wrong namespace but not in a way that causes any problems) and those are reflected inside the Assets/Scripts/ structure. I export them from the main project to the "Packaging Project" in a unitypackage form (selecting files and exporting a package the old way so they keep their structure), fix whatever need fixing and adding unit testing in the "Packaging Project" and then make a local (on disk only at the moment) package and add this back to the original project via the Package Manager. After compilation is completed I delete the original files under the Assets folder (the project does compile but with warnings of duplicated classes and all duplications uses the files under Assets as I expect them to). Up until now, that workflow worked great with all references to monobehaviours/components on GameObjects and on Prefabs made the transition to the new versions from the package (it's the same package always, I add files to it iteratively and update the version in the package.json file).

The package structure is as the following:
The root is called CommonLib_project and in it, there's CommonLib folder and the package.json file (and their meta files of course).
Inside CommonLib I have my Editor, Plugins, Prefabs, and Scripts folders (with their meta files of course).
Inside Scripts, I have a single folder called "common" and inside of it all the other folders (each one representing a namespace such as common.comm, common.utils, common.controllers etc etc). The 4 problematic scripts AND the asmdef file are as well inside common (as the namespace of these 4 scripts is just "common" and not "common.something"). From my understanding, scripts in the same folder as the asmdef file are also included inside of it so there shouldn't be any problem with that.

The main project itself doesn't have any asmdef files besides of those that come with TextMeshPro and any other package that have it (I think Facebook has one? anyway I didn't make any). As long as I don't compilation errors (I have some things that do need special handling in the transition and that's ok and of course I don't proceed with resolving those) I don't seem to have any problems accessing scripts that some of them under common.something in the package and other under common.something under Assets if those stayed behind (and some of them did).

So if I don't have these problems, why these 4 scripts specifically are losing references when I update the package? It's as if in the editor the objects forget what scripts they were expecting to have and thus not re-assigning the scripts.

Any other additional info that may help:
Unity installed on main project 2018.3.11 (upgraded from .3.9) and the Packaging Project is currently on 3.9.
Win10
Source control is Git but I can't see how it has anything to do with it as I don't currently use it for the workflow.
I don't use any special plugin/program/whatever to pack my files. I copy them manually and update them manually. Except for https://unitylist.com/p/iwo/Upm-Git-Extension but it doesn't do anything special if I use a local package from disk...
Also, the project was originally on 2017 and I've upgraded it to 2018 and it had tons of problems switching from "Nest Prefabs" the plugin to Unity 2018 nested prefabs. It might have something to do with it but before I've started the packing procedure I've resolved all the problems from the upgrading process and the project ran in production with no problems.

Please help me. This really hampers the progress of modulating the code base (on a project that is already in the app stores).

 

@manu73

I took upon my self to investigate further and I've found out some interesting things. The way I conducted the experiment:
1. I've created a new project [SOURCE] with some game object and some prefabs and I've put scripts on them.
2. the scripts are arranged in folders reflecting their namespaces structures under Assets/Scripts/
3. I've exported the Scripts folder as a unitypackage file.
4. I've created a new project [PACKAGING] and imported the unitypackage in there.
5. I've create a asmdef file at the folder where the first script appears (similarily to the real project at Assets/Experiment/common) and the package.json file inside Assets/Experiment folder.
6. I've copy-pasted Experiment folder outside the unity project.
7. And then using the package manager I've imported it from disk.
8. The import was successful, everything compiled and I got a warning for each script that there's a conflict between the packaged one and the original one under Assets and that Unity will use the ones under Assets.
9. I've deleted the Assets/Experiments folder and all the gameobjects lost their scripts, not associating them with the ones in the Packages.

• At this point, due to the conflict, the guids in the package were changed by the source project even though these files are in a folder outside the project.

This is consistent with my real project, unfortunately.

Next, I've tried to import at different order. Firstly, in the packaging project, I manually checked that the guids in the metas of the scripts remain as they were originally. And then I've deleted the scripts from Assets in the source project before importing the package.

It almost worked! For regular-non-prefabs objects in the scene - scripts restored.
For prefabs - scripts restored.
For nested prefabs - scripts restored. (also a prefab that has a child prefab and a non-prefab gameobject)
BUT for a nested prefab with a child game object that is not part of the prefab (in the hierarchy panel that child object is a grey box with a + sign meaning it's an override), it didn't work. THIS IS DEFINITELY A BUG.

So my conclusions are:
1. Scripts that without a doubt were not hurt from the transition from Assets to Packages are those who are not Monobehaviours and are created/instantiated during run-time. Or simply put normal classes or classes that derive or implement other non-Monobehaviours classes.
2. Scripts that were not part of the move regardless of their namespace are also safe (or at least so it seems and I need to test it out more).
3. Importing files with the same guids will always give new guids to the newer files and/or files that are not under Assets folder.
3. The links are broken and cannot resolve upon deleting the old files since the new ones have new guids and Unity will not try to resolve via script name but through guid only (I can see the logic behind that).

So I guess this thread came to this:
1. We need a tool to resolve conflicts upon importing scripts to let us choose which version to keep (a conflict where a script with the same name, namespace and guid are the same) but unlike your run-of-the-mill Git these scripts resides at different locations. So a feature request...
2. The bug described above.
3. Request to explain it in the manual when using packages in projects what the implications are moving scripts around.

 

ok.

 

Wow, I've just been fighting with this problem for quite a while until I came upon your answer and it shined some light on what was going on.
This definitely seems to be a bug on Unity's side, or at least an obscure behaviour.

In my case, it happened that a package GUIDs and the GUIDs in my project collided. This showed an error in the console. I deleted the duplicate assets from my project, and everything compiled correctly. However, all the GUIDs inside the package were changed and not updated back to the original package GUIDs, even after restarting Unity.
I could fix it by deleting the Library folder, so the package was downloaded anew.

 

The same issue happened to me in 2020.1.13f1

 

I reported this bug btw here

 

Ah, the issue was I needed to generate Script Assemblies for my package's directories that contained scripts and properly link their dependencies.

 

Same issue, I just resolved by put all scripts in `Runtime` folder (or editor, if it's relevent)

 

Why can't this be entirely automated? I wish we didn't have to think about these things.

 

So, I amongst many i'm sure, actually created this very tool.

It's not exactly pretty, and i haven't gotten much fanfare either, but with enough (and even better, some help!) i can make my tool much better. But yes, it does solve the issue of unity maintaining the metadata GUID tag of a monoscript, and yet completely forgetting then name, by batching through an entire project and fixing all the GUIDs (say from a old instance of textmeshpro or an asset you don't have the right version of etc, and fixing all the references to the old scripts to update them to the new scripts, for all gameobjects in scenes, prefabs, scriptable objects, etc....)

https://github.com/wafflehammer/Unity-GUID-Remapper---hxrmn

 

Thanks jerhap for the sharing, I double checked this has nothing to do with the name "Runtime", it is related to changing the folder hierarchy or renaming within the Unity Editor itself and not from the Windows Explorer outside. Initially I renamed it to "Runtime" folder, it works then I renamed back to "Scripts" folder name, export then imports to new project, it still works.

 

Thank you for this! If anyone is wondering how to use this, go to releases on the right column (under about), and download the exe. If you are about to fix scripts, when running the app, go for advanced, and for "good" class, select the old script file to be replaced, for "bad" class, select the new one coming from a pacakge for example, and run the app.
Took me a few tries to figure out how it works, but it works, and saved my sprint goals