Major bug in Unity 5 when importing clone or items of same project, with changed directory structure

Unity Engine
1

I just came across a major bug in Unity 5.

It is related to importing projects and file replacement.

As it seems the files in a project wont be replaced by the changed files of the same projects worked in another PC, when trying to update (making a unitypackage with the file and importing it in the project, not copy it manually) and have folder structure changed.

So if a script in Project A is in folder Scripts and in Project A Clone in ScriptsB, packaging the code from Project A Clone and importing to Project A will produce two separate files and all links will point to the original one !!!

This means that changing folder structure could break completly a project when it receieves updates by other team members or installations of the same project.

I think this is the most major bug of Unity 5 so far and should be the highest priority to fix, as it can completly break projects and add a lot of confusion.

2

Not a bug. If you are manually moving files around between projects, Unity doesn’t have any way to know what is supposed to what (outside of what is being packaged). Unless you are copying the entire project, it can’t know about “projects”. (otherwise the asset store wouldn’t work). If you want to manage the project between users, you should use version control. Git or SVN or something like that.

3

Sorry i did not make it 100% clear. I mean when packaging a code file (making a unitypackage with the file and importing it in the project, not copy it manually, so it retains all links). In Unity 4 the file would be replaced even if it was in another directory than the one in the imported packagefile. In Unity 5 this does not happen and it creates a duplicate of the file, with all links still pointing to the old file.

The only way to replace the correct file and keep the links to prefabs is to keep the exact folder structure. This was not nessesary for Unity 4.

What this means is that if i buy an asset from the store and change the folder structure to best fit my project and then try to update, all new changed files will create duplicates and the project will be broken.

4

Ah… gotcha. Yea, that should work.
I haven’t seen any problems with that in 5. Just gave it quick test and worked as expected. (exported a few files, renamed/changed file structure, and reimported) When you move/rename/etc, are you doing it from the project panel, or in the computer’s file system? (or could someone on your team be doing that?)

5

Probably this did not cause a problem because the files must be changed, otherwise wont need to be reinserted.

I import/export the package from the Project panel.

I have Unity 5.0.1f1, for reference

Here is how i replicate it

  1. Export a .cs file to a unitypakcage
  2. Do a small change to the file and move it to new directory
  3. Import package

This adds the before the change file to where it previously was, keeping both files and producing a “already contains a definition” of class error

6

Yup, that repro works as you describe. It doesn’t duplicate if you just change or just move, but does if you change and move. Though I also just tried it in 4.6.1p1, and it functions exactly the same as 5.

7

I use Unity 4.3.4 so maybe that broke in later Unity 4 versions and was tranfered to Unity 5.

This is a major issue that can easilly break any project or asset, hopefully they restore the previous behavior or at least give an option to duplicate or seek the same file and replace, even if it is in another directory.

This essentially makes it impossible to upgrade any store asset safely, if even minor changes have been made and directory structure has changed.

For example in my RPG i use more than 50 assets and i have most parented to grouping directories. This means i now get a completly broken project if i try to upgrade everything in Unity 5.

I never had the same issue with Unity 4.3.4. I think this should be handled as a number one priority, since it is a real nightmare for bigger projects.

8

I just did a small test again in Unity 4.3.4 and the file that was moved and editied gets found and it is replaced directly in the new folder by the unitypackage, so wont create any issue.

Probably the bug appeared in a later Unity version.

9

Any news on this matter ?

I am now stuck and stopped any updates to my project in case it breaks by files that have changed content and folder, hopefully this will be fixed soon and restore the Unity 4.3.4 functionality and proper file replacement.

Thanks

10

Anyone else come across this issue ?

11

Did you submit a bug?

12

No, i am not sure where to do this as it is not related to the editor but rather the import process. I will contact support for it though.

It is strange that it has not been brought up anywhere, as it can potentially break any project that uses assets very easilly.

13

In Unity go to Help > File A Bug

If it is a bug, It is pretty edge case. You have to be importing, moving and changing all at once to for it to occur, and even then it is a minor fix/easy to account for. Since it has worked that way for while, the use scenario is probably uncommon at best, even if it is considered a bug, it probably isn’t a high priority. Definitely file the Bug Report, but you should work around it, don’t count on it being fixed.

14

The problem with this is that i usually move all assets i buy in a custom folder, to keep the root tidy. This worked fine in Unity 4.3.4 and any asset update replaced files even when they were moved.

With Unity5, all assets i have been working with could break if the new versions have a change, since there would be both a change from the asset developer side and a move from mine.

So this problem is as easy to break a project as moving a folder. Of course can be worked around, by copying the duplicate file(s) code manually one by one, which may be near impossible though if there is a big number of files involved and way too confusing especially for me that use 50+ assets.

I will file for the bug as well and hope for the best.