Update: This is a bug in the Addressables system that breaks addressable content if the scripts defining the assets are moved to a different assembly. Should be possible to fix up, as it’s a pretty nasty edge case to have to identify and fix manually.
Summary: I moved some code files into a new assembly and now can’t load the assets that are based upon them them through the addressables system
Unity 2018.4.0f1, Addressables 1.5.1
Probably I’ve messed up something very basic here as this is my first time using Assembly Definitions, and I’m pretty new to addresables, but this is my issue:
I’m currently loading 2 types of custom asset through the addressables system (both inherit from ScriptableObject)
RTM.Localization.LocalizationSettings
RTM.Utilities.StringArrayAsset
I’m migrating my various modules into packages, so have started by splitting up the code into assemblies. This means the StringArrayAsset.cs file is in a new Assembly (RTM.Common). LocalizationSettings.cs is still in Assembly-CSharp (for now).
All the assets live in the main project folder (away from any assembly definitions) and I have rebuilt the Addressables content and checked all the addressables settings seem the same as before.
After moving the code into my new assembly, I can still load LocalizationSettings, but not any of my StringArrayAsset assets. The assets look fine in inspector and I can still use them as direct references, but can’t load them via adressables
Exception encountered in operation UnityEngine.ResourceManagement.ResourceManager+CompletedOperation`1[RTM.Utilities.StringArrayAsset], result=‘’, status=‘Failed’: Exception of type ‘UnityEngine.AddressableAssets.InvalidKeyException’ was thrown., Key=rtm/loc/strings/checkpoint UnityEngine.AddressableAssets.Addressables:LoadAssetAsync(Object)
rtm/loc/strings/checkpoint is correctly set up as an address in the Addressables Settings. Error occurs in both editor and player. The LocalizationSettings loads fine
Oh hey, I apparently fixed this by accident, BUT there appears to be a pretty major bug/flaw here. All these assets are auto-generated and after a re-generation their serialised data has changed (which wouldn’t normally happen unless the source changes (see partial diff below)
I don’t know what that field is, but after this update (and a rebuild of my addressables), all my addressables loading works fine.
The major flaw here is that if you migrate a script between Assemblies all user data based upon it silently breaks?? This is not an issue for me right now, but if this was actual user data it would be a massive pain to re-create all the files manually
UPDATE: actually, that’s not the only change. After migrating the other script I found that the probable culprit is the AddressableAssetGroup settings. Turns out the Assembly is serialized in there but hidden from view and does not get ujpdated unless you a:
Set the asset non-addressable, set it addressable and put it back in the correct group, OR
Seeing as the AddressableAssetGroup has the GUID of the asset, it can actually look up the script and do an automatic fixup if needs be? I’m not sure when this happens but I guess this is now clearly a bug
This happens with plain AssetBundles: if a class is moved to another assembly, bundles which reference them will not be able to find them until you force them to be rebuilt.
Well, Unity definitely should handle that, because it’s HUUUUGE pain recheck addressable assets manually. I’m faced with same problem today, when I added asmdefs for including unit tests. @davidla_unity or you can suggest any thing?
I also want to point out how hard this is to trace down. In my case it throws an InvalidKeyException on some sprites, which I’m not sure what may the reason behind be. I’ve spent a long while trying to trace this back to check which asset or GUID (the Key) is, inside the Addressables package, and couldn’t find a way to.
On the other hand, I also failed trying to write down a rule.
I know for a fact that asmdefs are causing this, because just adding or removing them (changing repo branch, with no other changes whatsoever) fixes and unfixes the situation.
Did someone end up finding a proper solution to this? I think I’ve run in to the same issue myself. Failing to load an asset due to invalid key yet it’s set up correctly, but it is compiled under a different assembly.
