Why is there no AssetDatabase.SetGUIDForAsset()?

I'm really confused as to why there isn't a way to actually set the GUID for an asset with the Asset Database without going through and directly modifying the guid line by hand in the *.meta files. This is a hack and is generally unsafe for normal use.

"Why do you need this?"
We build assets for the Asset Store. Did you know that all assets (Scripts, Models, Textures, Scenes, even folders) should have the same GUID between release versions? This means that if you want to branch your source project to build a release, you had better have your meta files set to visible. It gets even worse if you try to do a compiled assembly release: your MonoBehaviour scripts end up getting a separate GUID that is auto-generated when the assembly is imported (note: yes, we do keep assemblies [DLLs] and source code in separate projects). This means that all script references that referenced your MonoBehaviours or ScriptableObject in .unity, .prefab, or .asset files will suddenly break and require manual updates. So rather than being able to simply say "Hey, AssetDatabase, update the references for this GUID to this new one" you have to go into the .meta files, parse the GUIDs, and fix up things on your own.

Frustratingly, the AssetDatabase has all of this information (and then-some). It's Editor-only so I'm really, really lost as to why this kind of functionality is locked away from developers to help them manage their systems. Not only would some GUID-updating APIs help people manage their assets but it would actually be a helpful hint that this is an important part of the system (many people who build Assets are initially surprised at the GUID warnings they see show up once they've done a few Asset updates).

(By the way, simply changing the GUID in a meta file and doing an AssetDatabase.Refresh() does not appear pick up the changes - it's as though only actual asset files are watched for changes and not their associated meta files...?)

Why don't these exist?
I'm curious as to why these don't exist. I guess it's possible that no one has requested them before but I highly doubt it. I'd rather hear what the rationale is for keeping people from updating their settings like this. To be clear, the three APIs I have in mind are:

• bool AssetDatabase.SetGUIDForAsset(string path, string guid) - Takes a path to an asset and a custom guid. It will verify that no other asset in the project currently has that guid. It will then update the AssetDatabase with that guid, adjusting any references to it to maintain compatibility. It is understandable if this process takes some time - theoretically it's something that should rarely happen. Returns true if the change was committed, false otherwise.
• AssetDatabase.RepairAssetReference(string oldGuid, string path) - Takes a guid that is presumably "missing" from the current database but is found to be referenced from other assets (this is usually the cause of the "Missing Script" errors/warnings). It then goes through all assets, looking for oldGuid and updates those references with the guid for the asset specified by "path". This would allow people to write utilities to fix up references when they make breaking changes.
• string[] AssetDatabase.FindHangingReferences() - Searches all assets looking for guid references that do not exist in the AssetDatabase. All such guids are returned in the Array. These can be used, for example, in the "RepairAssetReference" method above. This is particularly useful for people who regularly maintain a source code project and an assembly version of the same project.

Any thoughts and input would be most excellent.

- Eric

 

My input is: The whole process of updating packages is nearly unworkable. And the more versions that are released, the crazier it gets. Importing someones packages almost always results in the import of obsolete scripts from earlier versions of unity that you have to manually weed out, or repair by reimporting all the standard assets.
The whole process would be simpler if they would manage this better - They could enforce that all packages go into a unique folder, for example, and then wipe this out and reimport. They could detect that a package needed standard assets, and NOT INCLUDE them in the package when it was built, and pull them in automatically (if needed) at import time. Personally, I'd rather not micromanage assets. But I feel your pain.

 

Unity developers claim to be working on, from what I understand, a complete overhaul of the packaging system (heard through the grapevine). This does not help us now. The request I put in above is, I would think, fairly lightweight in terms of development time to get us something helpful until the new hotness arrives.

The other thing is that it would really help to simply know why they haven't added such useful methods: is it so very fragile/dangerous that the whole system would come tumbling down? If it isn't terribly performant, mark it as so (the AssetDatabase is Editor-only, after all...).

 

Why isn't the user prompted to input a GUID for each file of the project in the first place? the answer is (IMO) is that the engine (and specifically, the AssetDatabase) is responsible for assigning and managing these GUIDs. It is the owner of all of this functionality, therefore you really shouldn't be messing around with it.

Having the GUID exposed in textual form does not imply you should mess around with it (although that does help work around some of the bugs that are not yet fixed, as you mentioned yourself).

I believe this was already included with 5.3, at least from what I remember reading in the beta group back at the time. Maybe not all things were fixed, but it sounded like they're heading in the right direction.

 

Ideally, you would be 100% right. However, as the system works and Unity expects asset developers to manage things essentially requires that "you mess around with it." Yes, it would be most excellent if all of that was magically handled in the background but it just doesn't work. The number of asset developers who don't understand the issues that crop up because of the system's implementation is pretty staggering. That said, it's not super surprising as there's little to no documentation on how this stuff actually works. Most people seem to understand it after poking around forums/ask/etc. for a while. That's how I learned about it, at any rate.

Agreed. I'm not asking about that, though. You could argue that the APIs I'm asking for would mean that we would no longer need to put Unity into this "show visible meta files and also force text serialization" in order to properly manage asset development anymore.

And, to be clear, I expect that these APIs would not get used by very many people. Mostly asset developers or lead engineers who are working on massive asset migrations, fixing script renaming/etc. bugs, or whatever.

This was my take on it from those discussions on the beta list. Glad to hear that the other whispers were of something far greater. That said, @superpig, any word on why those APIs don't exist? Or if we could have them (or something like them) while we wait for the new hotness?

 

I guess I can understand that. It's just that the longer we go without seeing "the future" the more this starts to feel like a drastic oversight. The number of hoops that people without source code access have to jump through in order to play nicely with the Asset Store and not piss off customers by causing confusing warnings or errors is pretty large.

And that number is growing: one simple example is how renaming an asset in a unitypackage works with respect to GUID. Unity 4.x treats it one way, then Unity 5.0-5.2 another, and now with 5.3 we get yet another way. For the record, Unity 5.3 now seems to ignore the asset rename - it sees the GUIDs are the same and will overwrite the file contents but not update the name with the change. To some extent this is preferable to previous versions wherein it would simply create a duplicate file, complain about GUID conflict, and then assign a new GUID (meaning that once you'd made a change to an asset name, if the user didn't delete the original file it would constantly create new duplicates).

I mean, you could say the same thing about a lot of the more advanced graphics features, right? There are entire regions of the API that I've never touched in the years I've been developing with Unity (and haven't seen anyone touch on any project I've been a part of). But that doesn't mean that someone doesn't give them the time of day. What I meant to imply is that this isn't something that everyone under the sun would need to touch - like GameObject.transform or something. It's something that could assist people dealing with certain unfortunate situations - potentially save people a lot of headache when they encounter such an issue by enabling a way to automate fixes.

Perhaps the best part of that video is the overlay comment of "I have probably spent a total of five hours researching this issue, and I know that I'm not alone. It amazes me that this problem can be so common and there's no built-in way to resolve it. Hopefully one day it will be fixed." I'm not trying to imply that this would solve "all the problems"™ but it would enable users to do something in their own workflows for this issue [and others]... As a bit of editorial commentary here, I'm personally not surprised that the video I linked was created by an [ex] Asset Store developer.

I hear that. Unity is a big system with lots of moving pieces and this is just one item in a massive list of "feature" requests. It's just that this would enable a lot of people who either - A) wind up breaking AssetDatabase asset connections due to renaming, etc. or B) create content for the Asset Store - to work better with Unity.

One quick note: I know everyone keeps saying "We're working on a new system for package updates!" but unless this comes with a massive overhaul of the AssetDatabase itself, I don't yet see how this negates the need for being able to adjust/replace certain asset GUIDs by hand for the odd cases. I do see how such a system might work for people dealing specifically with packages but I can't see how it would help people fix the hanging/missing references issue due to some other kind of change in a project.

That all said, this one line is really interesting: "[such APIs would] be guaranteed to conflict with some other particular changes that we're hoping to make in the future." That setting a GUID would conflict with whatever new hotness you're cooking up is really interesting. Whatever this new system is, I really do hope it's comprehensive and truly negates all these issues Because, man, jumping through Unity hoops is something I would really like to stop doing

 

It would be really nice to have a way to set a specific guid on an asset as it imports. This would be super helpful for source control when there are parts of the project that we don't want to source control because that content is automatically created... and yet those guids end up referenced in other parts of the project. This would be a pretty useful tool to have in our tool bag instead of having to fight the editor tooth and nail to do it.

 

That's why I discarded asset and use XML instead. Unity's asset/guid/fileid based serialization system is quite unreliable, especially when using `ScriptableObject` in editor plugins.

 

Alright.
It has been five years and we are waaayyy past Unity 5.

Could the Unity Team please look into adding a

AssetDatabase.SetGUIDForAsset(string path, string guid)

method or similar?

It doesn't have to do ANYTHING but set an asset's GUID.
That is all we want and it is all we need.

I don't care if I could totally screw up my project using the method irresponsibly — because if I do, that's on me.
It's not like we can't manually edit a meta file's GUID or anything... Don't you trust your users to not come and complain if they do something STUPID?

Please, just provide a way to set the GUID of an asset programmatically.

 

Couldnt you simply read and edit the meta file's guid entry?

 

Only in some circumstances. The GUID gets complicated when you do things like reference classes within assemblies... Not unsurmountable if you know what you're doing (you need to modify both the fileID and the guid fields in the YAML structure appropriately), but a single API to handle this would be nice. To that point, my original suggested APIs don't quite work as written - there's some extra context that would be required to handle things, but the concept is still valid, I think.

 

Especially with Addressables it's nice to know the GUID before creating the asset. Now I have to create the asset, set the GUID and then serialize it again.