Warning: Type DefaultAsset is in editor assembly UnityEditor

I started seeing this warning in a recent Addressable release. It happens when entering play mode:

Type DefaultAsset is in editor assembly UnityEditor, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null. Asset location with internal id Space_Soldier/Meshes/SoldierArm/SoldierArmHardware will be stripped.
UnityEditor.EditorApplication:Internal_CallGlobalEventHandler()


If I search for "SoldierArmHardware " in the Addressable window, I get this:



Basically it's a 3rd party package from the asset store, which happens to have a Resources folder in it. I'm wondering the significance of the warning, and what I should do to prevent it?

 

You can modify the built-in asset group to not include assets from Resources folder. I'm not sure if there is any benefit from including them in the first place, since they are also packed by default into the player build by Unity? @unity_bill ?

 

"including them" does not actually mean having addressables add them to the build, because as you said, Resources are automatically in the build. when we "include them" it means that we know where they are, and support Addressables.Instantiate("some thing in resources"). This is a feature for people migrating from Resources. The more I think on it, the more I think it should be off by default.

In your case, you don't care about the warning, and can hopefully get rid of it by following @stefankohl's advice. The significance is if you had an asset in your project that you explicitly marked as addressable, but was in fact an editor only asset, we felt we should warn you that it won't end up in the build. perhaps we shouldn't.

 

Sorry to necro-thread here, but I'm trying out the Addressables system for the first time and came across this issue.

In my case, my DefaultAsset is a binary data structure that the editor doesn't really know how to use. I need it included and then I reference it as a byte[] and deserialize it myself.

It seems like this warning suggests my asset cannot be Addressable. Is that true? @unity_bill

 

i too would be keen to know the answer to this 2020 question . Similar issues but with glb files in addressables system.

 

The way I ended up solving this problem was by making a ScriptableObject that holds onto the byte array. The scriptable object is able to be loaded by the Addressable system, and I can deserialize the byte array myself once it's been loaded

 

I should add, I don't really like this answer.
If we can name it something like ".bytes" and have it work as expected, then it sounds like it's just a whitelist of known, arbitrary file extensions.

Rather than forcing the developer to use ".bytes" and broadcast a file's purpose to the end user, it would be better if there was a way to provide the ability to add whatever is necessary to handle a registered file type.