Upgrading a plugin in Unity 5 duplicates files. If you delete the files first, BROKEN

I see no way to solve this. It appears that upgrading plugins from the Asset Store has been broken in Unity 5. In Unity 4, you could perform an in-place update of the plugin, without deleting any files. The files in the package would be updated with the new versions and you’re ready to go.

In Unity 5, if you try an in-place update, you get duplicates of each file with a " 1" at the end of each file name, which doesn’t compile. If you first delete all the plugin files and folder before grabbing the new version, that doesn’t happen, but all Inspectors that use those scripts are broken and say “Missing (Mono Script)” and you have to drag that new script (if you remember which one it was) into there to fix it. Times 100 if you have 100 files assigned already from the old version.

There really must be a normal way to upgrade plugins / packages with Unity 5, but for the life of me I can’t figure out how to do it. This is really unacceptable and I wish we could go back to Unity 4 behavior on this.

Anyone else hate this or know why it was done? Seems more harmful than helpful to me and a most users I’ve spoken to.

Please advise,
-Brian

Are you using ‘import package’? What method are you using to ‘update’ a plugin?

If you’re using ‘import package’, and the update ONLY comes as a package, try importing that package into a empty project. Then just copy and paste the files imported into the new project.

I’m updating a plugin through the asset store, which is “import package” yes.

I will try that, and I hope it works, but why should users be forced to do weird workarounds like that? Extremely inconvenient for users of our plugins.

Thanks for the response.

It might be a bug… not sure why it’s acting different from Unity 4. Issue a bug.

I’m just trying to give you a way to solve your problem currently as it stands. A bug fix can take time (even if Unity considers it a bug).

If this is for your own packages you’ll be distributing. May I suggest you actually write your own updater for your stuff. I don’t use many packages, but the ones I do actually have updaters built in.

One of the main reasons I suggest it is that a ‘unitypackage’ really just writes files down onto disk. It doesn’t really do anything more complicated (as far as I know that is). What happens if the hierarchy of your package changes? What happens if some files that were in a previous package need to be removed or renamed?

If you have a built in updater you can download the files necessary (independent of unitypackage) and write what needs to be written, rename the meta files as necessary, etc. Use the unitypackage for distribution, updater for updating.

EDIT - so I wanted to check, and I checked out the binary data behind a unitypackage. It basically looks like a wrapper/container around a tar file.

7zip actually opens it just fine.

Yes, I’m aware of those problems. Previously, deleting the old folder before importing the new solves those problems. No longer in Unity 5.

I’m not sure how an updater would work. Can you describe one? I don’t believe I’ve ever used a plugin that has an updater. And I use dozens of plugins.

I’ve reported it. I’ll see what they say.

Well one example of a package with an updater is AronGranberg’s A* pathfinding library:
http://arongranberg.com/astar/

I don’t see how in Unity4 deleting the old folder before importing the new solved those problems. I still use Unity4 for my main project, and if you delete a folder that contains scripts… the objects that reference those scripts loose those references. Even re-adding them doesn’t work, because new meta files are created… and script references are handled by the guid stored in the meta files. If new meta-files are created, then the guid changes.

Thanks, I’ll take a look

I don’t know what to say, I’ve done it probably 100 times and never had that issue on Unity 3.5 and Unity 4 both.

Brian - I haven’t run into this problem when importing updates from the Asset Store. I am having a different problem, though, that I’ll document at the bottom of this post.

These scenarios work for me:

  • Create project in Unity 4. Import package. Import newer version of package.
  • Create project in Unity 5. Import package. Import newer version of package.
  • Create project in Unity 4. Import package. Open in Unity 5. Import newer version of package.

It sounds like the package you’re importing has new metadata. This would happen if the author copied the script files without their corresponding .meta files, or if they duplicated them and renamed them back to their original names. If you import a script file with different .meta file, Unity keep the original script and .meta file, and it’ll import the new .meta file and rename the script file with a “1” as you reported.

Since your assets (scene objects, etc.) reference the GUIDs in the original .meta files, they won’t find the new scripts, giving you the “Missing” error.

The author can fix this by associating the script files with their original .meta files, but he’ll have to do it manually. Here’s one way:

  • In a new project “A”, import the old package.

  • In a new project “B”, import the new package (with the "bad’ .meta files).

  • Exit Unity.

  • In the OS, copy the files (except the .meta files) from “B” to “A”.

  • Open project “A”. Export the package. This exported package will now be compatible with older versions.

Now, to my problem with Unity 5 (in case this is also somehow related):

I have a package that was created in Unity 4. It contains some ScriptableObjects. The instance IDs of those ScriptableObjects are signed ints, which is what Unity 4 used for serialization.

Unity 5 now uses unsigned ints for serialization. If I set the project to Mixed serialization (versus Force Text or Force Binary) before importing the package, it correctly imports the serialized data. However, if I set Force Text (or Binary), the serialization is broken.

After importing in Unity 5 with Mixed serialization (which works), I can switch to Force Text afterward just fine.

Unfortunately, if I export this Forced Text version as a new package, it still won’t import correctly into a new project set as Force Text. (I opened a bug report on this.)

Hmm, I think it was a weird snafu when I added a namespace. Can’t reproduce it in a new project.