Bug "ArgumentNullException: Value cannot be null." When using AssetReferenceT<T>

When I try to drag and drop a Cube Prefab to the AssetReferenceT<Cube> field in the Scriptable Object, I got error. I have sent a bug report about this. Here is the Issue Tracker.

Addressable Version: 1.21.18
Unity Version: 2022.3.2f1 LTS

 

This is not a bug. Your generic parameter is of type

Cube

, which is not an asset that can be referenced using Addressables. The T refers to assets that are tracked by the AssetDatabse, which a script or MonoBeviour doesn't comply with. T can be

GameObject

,

ScriptableObject

,

Texture

, etc., but not a MonoBehaviour as they are not assets.

Addressables has a

ComponentReference<TComponent>

script in its samples, but you'll have to inherit from this and implement the TComponent type parameter explicitly for it to work (check the documentation above the class).

 

"Before Unity 2020.1, the Inspector window couldn't display generic fields by default. In earlier versions of Unity, you must make your own non-generic subclass of AssetReferenceT instead. For more information, refer to Create a concrete subclass." Link

If that is the case they need to write it on the documentation explicitly....

 

I think you are quite wrong. I just tested that I can assign AssetReferenceT<Cube> with a simple script. But I can not assign it via the Inspector.

 

With your script, you assign the asset guid, which is the guid of the asset as registered in the asset database, which is the game object. It doesn't reference the Cube script, and the constructor doesn't itself check that the provided guid refers to a valid object. If you would attempt to load it through Addressables, you would get the game object, and not the Cube on the game object. With your assign test case, you could assign a Player or any other script to an AssetReference<Cube>. That's where the null ref exception comes from: it can't validate that the provided object is of the requested class (GameObject versus Cube).

The

ComponentReference<TComponent>

explicitly supports components which will return the requested type of component when being loaded from Addressables. So in your example, assigning would work, but loading wouldn't. This is behaviour that's gets overridden in the

ComponentReference<TComponent>

class and will properly validate the component on the game object being present.

Perhaps they can update the documentation to amend it with this info, but Addressables still works on Unity versions 2019, which doesn't offer this feature. As long as backwards compatibility exists to that version, it should at least mention that they should implement it in an explicit class.