Bug (WORKAROUND) AssetReference drawer disappears in Dictionary

Hello everyone.

I found a bug in Addressables 1.10.0. I use Odin Inspector & Serializer add-on for serializing Dictionary field in my script. Unfortunately when AssetReference is used as dictionary key or as a part of structure or class that is a dictionary itself, the drawer causes to fail: the field simply doesn't render in inspector, but I still can access it via right mouse button click.
There is the very similar post on forum already: https://forum.unity.com/threads/assetreferencedrawer-does-not-dirty-the-serialziedproperty.568894

I used a little workaround for that and I guess this post will be useful for everyone who faces that situation.

There is a breaking piece of code:

Spoiler: Look at me!

Code (CSharp):

1. [System.Serializable]
2. public struct A {
3.       public AssetReference a;
4. }
5.  
6. // ...
7.  
8. // it's really no difference between stock SerializeField and OdinSerialize in this case
9. [OdinSerialize]
10. private Dictionary<int, A> dict;
11.  
12. //...

Spoiler: That's how it looks like

After a couple of minutes of debugging I found that serialized object has Sirenix.OdinInspector.EmittedUnityProperties.EmittedSOProperty_a_UnityEngine.AddressableAssets.AssetReference type, not like UnityEngine.AddressableAssets.AssetReference in regular structures.

The problem part of code inside AssetReferenceDrawer.cs:

Spoiler

Code (CSharp):

1. public static T GetActualObjectForSerializedProperty<T>(this SerializedProperty property, FieldInfo field, ref string label)
2.         {
3.             try
4.             {
5.                 if (property == null || field == null)
6.                     return default(T);
7.                 var serializedObject = property.serializedObject;
8.                 if (serializedObject == null)
9.                 {
10.                     return default(T);
11.                 }
12.  
13.                 var targetObject = serializedObject.targetObject;
14.                 // targetObject has been serialized differently
15.  
16. // ...

At the end of the try-catch block it tries to get value from FieldInfo, that's wrong for dictionary serialized field:

Spoiler

Code (CSharp):

1. // ...
2.                 var obj = field.GetValue(targetObject); // causes a fail and goes to catch it, returns default class instead
3.                 return (T)obj;
4. //...

The result of everything above is a null value in m_AssetRefObject variable. When it's null, the field won't be rendered in inspector.

I used a fast workaround for this situation:

Spoiler

Code (CSharp):

1.         public static T GetActualObjectForSerializedProperty<T>(this SerializedProperty property, FieldInfo field, ref string label)
2.         {
3.             try
4.             {
5.                 if (property == null || field == null)
6.                     return default(T);
7.                 var serializedObject = property.serializedObject;
8.                 if (serializedObject == null)
9.                 {
10.                     return default(T);
11.                 }
12.  
13.                 var targetObject = serializedObject.targetObject;
14.  
15.                 // add another one condition for descending a hierarchy
16.                 // (just check the type of target object: is it not a AssetReference itself)
17.                 if (property.depth > 0 || targetObject.GetType() != typeof(T))
18.                 {
19.  
20. // ...

After such manipulations the problem is gone.

Spoiler: That's how it looks like now

This solution has a con: if you use an array of AssetReference, there will be $0 instead of a nice variable name label. Probably it should be fixed inside DescendHierarchy method.

 

Bump for developers of Addressables.

 

Hi! I was a bit busy and haven't filed a bug report. Just tried a new version you mentioned. The bug is still here. Look at the picture inside a spoiler.

Also I posted a gist with workaround changes in version 1.10.0. You can diff it with vanilla one:
https://gist.github.com/CheeryLee/ac726bd688ec0abdafcd6af05036b25f

Spoiler: Look at me (1.11.2)!

Spoiler: Workaround for 1.10.0

 

I'm here to say that the bug is still presented in 1.13.1 in Unity 2019.4.6.
My workaround is still much helpful. It's a bit strange why you don't want to use it to close the error.

 

I'm also experiencing this issue. CheeryLee's workaround solves it for me - but I can only figure out how to apply it by editing the code in my Library/PackageCache folder, which doesn't seem like a great solution (as it keeps getting invalidated and deleted). Is there a correct place to apply this workaround, CheeryLee?

EDIT: After some further googling, I simply copied the addressables package from Library/PackageCache to <MyProject>/Packages.

 

It's definitely in Unity's package cache in AppData, if you are using Windows.

 

This is appears to still a problem in 1.16.10.

 

Ticket created (but the Unity team tells me not to share the error url).

 

Still present in 1.18.11

 

they still haven't fixed it in version 1.18.19

 

Most likely due to same issue here:
https://forum.unity.com/threads/assetreference-drawer-in-custom-editor.730556/
Custom property drawers don't play nice with unity's assetReference inspector, going back to using lists since I don't want to do the work around others are using of creating a ton a scriptable object wrappers.

 

this is a huge bummer

 

We'd love to see this fixed, we use custom editors and Odin to improve out workflows, this limitation is extremely inconvenient and nullifies much of the utility of our custom inspectors.