Here is the message I was sent regarding this issue:
So it sounds like it is indeed to the meta file’s GUID that needs to be adjusted rather than the DLL’s GUID. If anyone figures it out, let us know. I tried contacting the person who sent me this email but have not received a response.
To be honest I don’t really understand the reasoning. Most if not all Asset Store publishers store their assets in a specific folder structure, and files are only overwritten if the folder structure of one package matches another (correct?). I have yet to see two packages that have matching folder structures. This seems like an unnecessary change for an issue that will be relatively rare, but perhaps I am overlooking something.
I’m wondering if this change was intentional, or if it is a bug. If it’s intentional, what do they expect Asset Developers to do about upgrading? Just adopt the mindset of requiring a clean slate every time you import a new version to the project? (Though this doesn’t help if you have multiple assets using a ‘Shared’ folder).
Alternatively, could Unity provide a way of making certain that the GUID in metadata does not change unless there are actual changes to the asset?
I’m not sure what you mean by your last sentence. If there’s a change to the asset, wouldn’t we want the GUID to stay the same so that the asset is overwritten by the “altered” asset (rather than creating a new copy)?
1- My DLL file has not changed since it was made, so if VS assigned a GUID it has not changed either. (I’m getting ready to load VMware up and check the DLL project in VS as we speak.)
2- The only other files in the folder are (1) .CS file and (2) .TXT files. Typically, I update the .CS and the Version.TXT file. However ALL 4 files are being incremented when updated. I don’t get it.
Maybe this is a partial cause of the isuee, no clue: After I’ve done all my coding for a recent update, I copy my .CS & Version.TXT file from Unity 5 over to Unity 3 for submission for backwards compatibility. The DLL and other .TXT file remain unchanged. Maybe it’s that, that is part of the problem?
*Scratches head in befuddlement. This is gonna drive me to drink.
In all seriousness, something so simple should not be so dang’d complex/confusing.
EDIT: Checked VS, yes it has a GUID as expected which has 1 value. Then checked Unity by running: “AssetDatabase.AssetPathToGUID” for the DLL file from within the asset under both versions of Unity 3&5 and both return differing GUID’s. Which I believe has been mentioned prior as well, Unity GUID’s not matching the DLL GUID. So 3 differing values in all.
Here is what I did and it seems to have resolved the issue.
Enable Meta files via Edit → Project Settings → Editor → Version Control (Visible Meta Files).
Make a copy of your project that contain the DLL’s/other files that are having the duplication issues.
Upgrade the copy to Unity 5.
Examine the meta files of the problem files. The GUID of these files will have changed. For each file, open the meta file in the original pre-upgrade project and set it’s GUID to the GUID of the file from the upgraded project, saving each file. The project will recompile after each save (assuming you click on the project after saving).
Now, if you upgrade the original project to Unity 5, the GUID’s remain the same. I am guessing they used a different algorithm to assign the GUID’s in Unity 5, but this algorithm is only used on some files (DLLs for example), while most other files retain their GUID’s from Unity 4.
When you update a DLL or other problem file in your base project (the one you’re using to submit to the Asset Store), you may need to make sure the GUID doesn’t get reset to a different value. It might be a good idea to store all the Unity 5 GUID’s in a file so you can check this.
Again, this is what seems to work for me. I’m not saying it is THE solution to this problem. Please post if this works for you!
I see what you mean, I reimported multiple old versions of my project into Unity 3 to check the GUID’s in play and they remained stable. Import into Unity 5 and viola, it changes as you mentioned.
Just messed with it a bit more even going so far as to delete my assets folder structure and reimport the asset, and received an error complaining about the GUID’s of the folders already being assigned even though they had been deleted prior. I think that this is going to be a very interesting issue.
I see you have done some testing and found that different projects produce different GUIDs for the same asset. Were the projects using the same version of Unity?
I any event, I’d be interested to see how they respond to the issue of not knowing what the GUID is on a client’s machine. How are we suppose to ensure our GUID matches when it could be anything?
All my testing was done using B21. I might be doing something wrong in my packaging process, but the fact remains that I have clients in the wild with my package, and random GUIDs.
Hopefully they have some sort of secret method to ensure the GUID’s are all the same . . .
Otherwise, this change will have to be reverted. There is just no way the threat of files from different packages overwriting each other is great enough to warrant the headache that this change will cause.
If a Unity employee wants to chime in on this issue, I know we would all really appreciate it.
Good to hear. This change is certainly an annoyance. Add in the undocumented steps that seem to be required to account for this when distributing a pkg from Unity 3 or 4 and it just compounds the issue.
Hopefully it all gets sorted out and things go back to being simpler again.
As these libraries share files, it becomes a nightmare of conflicts instead of smoothly overwriting like in older versions. To solve, I have to import each unitypackage to it’s own project, then manually merge and overwrite files in my main project. I have to do this every single update, and updates are frequent. It’s a chore and frankly, not something I’m interested in letting go on much further, so it’s easier to just skip using asset store.
Optional pop/checkbox suggestion for import:
When it happens with high profile assets like megafiers and megashapes, surely it’s a problem solved by having an import checkbox for this sort of thing, so that unity can overwrite the files and merge guid’s in the project, specifically scanning the imported assets and resolving conflicts by changing guid for all imported assets to match.
Done optionally should work fine with source control and in upgrading. You should understand what a stressful chore it is updating assets which share resources with this new behaviour.
Assets within Unity are defined exclusively by their GUID (the guid defined within the .meta file). It is like this for many important reasons, for example, renaming a file in the Project will not break all the references to it within your scene.
To this end, we must always take the GUID as the defining piece of information for the file, the name is secondary.
When importing a package into Unity, it is important to adhere to this rule as well, and not create ambiguous exceptions. For example, when importing a package that contains a path and filename that already exists in your project, but for a different reason entirely (this will always have a different GUID), it is important not to override the existing asset.
So, if you are creating packages with assets that are upgrades of existing assets within previous packages, it is important to ensure that those assets are packaged with the same GUID, not a random new one. Keeping consistency with this is not only good practice, but keeps the upgrade chain consistent throughout the lifetime of an asset.
Previously, there was code in Unity that allowed this ‘override with different GUID’ behaviour. This was a bug, and caused a lot of other issues with package importing (as mentioned above).
The behaviour you are seeing is a fix. Please update your package creation workflows to define assets within your packages by their GUIDs.
This can either be done by ensuring the GUID within the .meta file is consistent, or if you are creating your own packages without meta information (just source assets), that the GUID encoded path to the asset is consistent.
Thanks for the in-depth answer, but is there detailed documentation on how we can make the GUID the same through many iterations of the same package? In the bug report I submitted, I mention that I took my package, and imported it in three different projects. For each different project, the GUID was different.
People keep saying that the real way to identify a file is by its GUID, but never say HOW we can ensure the GUID stays the same. Also, my package is already on people’s machines. If the fix to having a consistent GUID is through the packaging process, then it’s too late for all my clients; they will have duplicate files when they upgrade to Unity 5.
Yes, the behavior we see in Unity 4 might be a bug in your eyes, but Unity has been acting like this for so long that people have started relying on this. This is a huge change, and will cause many problems to people not participating in the Unity 5 beta.