Search Unity

[BUG] "Could not produce class with ID" errors in IL2CPP builds when using custom assets

Discussion in 'Addressables' started by Elringus, Aug 17, 2019.

  1. Elringus

    Elringus

    Joined:
    Oct 3, 2012
    Posts:
    426
    When running a build (Windows standalone) using IL2CPP with addressables (v1.1.7) enabled, "Could not produce class with ID 2089858483." errors are logged. I guess some addressables type is getting stripped. Is this a known bug or should I file a bug report?
     
  2. Elringus

    Elringus

    Joined:
    Oct 3, 2012
    Posts:
    426
    Here is the full log:

     
  3. Elringus

    Elringus

    Joined:
    Oct 3, 2012
    Posts:
    426
    Actually, the issue seems to be with custom assets. When the project contains custom assets (imported with UnityEditor.Experimental.AssetImporters.CustomAssetImporter) assigned as addressables, in IL2CPP builds "Could not produce class with ID" errors are logged per each custom asset.

    I've submitted a bug report (case 1177321) and created a reproduction project: https://github.com/Elringus/AddressablesIssue
     
    unity_bill likes this.
  4. Elringus

    Elringus

    Joined:
    Oct 3, 2012
    Posts:
    426
    Just received a reply from QA stuff that the issue is closed as duplicate of this one: https://issuetracker.unity3d.com/is...e-asset-bundle-using-scripting-build-pipeline

    I believe this is a mistake, as the other issue is about editor-only assets (specifically animation preview clips), which shouldn't be included to the build. My issue is about runtime custom assets that are included to the build and cause addressables to emit errors.

    This other issue is not even marked to be related with the addressables package and has been created 2 months after my issue.

    @unity_bill @QA-for-life
     
    faolad likes this.
  5. unity_bill

    unity_bill

    Unity Technologies

    Joined:
    Apr 11, 2017
    Posts:
    954
    They are dupes, but not for the reason you perhaps assumed. I can elaborate.

    Some editor types in the engine were not flagged properly as "editor only". The result is that during build, they would be included, but then they could not be deserialized at run time. Two examples of this are PreviewAnimationClip and ScriptedImporter. I'm not sure how things got this far with these bugs being in place, but they are there.

    So they are related, and being fixed. The problem is that they require an engine change. The issuetracker link you posted is in progress (code mostly done from what I can gather). That'll mean it'll fix some alpha version of 2020.1, then backports to 19.3, 18.4, 17.4 (and perhaps 19.2) will begin. I don't know the time frames on these.
     
    Elringus likes this.
  6. Elringus

    Elringus

    Joined:
    Oct 3, 2012
    Posts:
    426
    Thank you for the clarification! I'm still a bit confused though. The repro project I've sent for the issue is not using any editor-only assets; it's just a custom type inherited from `ScriptableObject`. It does use `ScriptedImporter` to import those assets, though. Does the errors have nothing to do with the custom assets, but caused because the `ScriptedImporter` is being used?
     
  7. Ryanc_unity

    Ryanc_unity

    Unity Technologies

    Joined:
    Jul 22, 2015
    Posts:
    249
    When an asset is imported a lot of additional data is generated and cached, such as the import settings used. Same applies to your custom asset. In your custom asset case, those import settings are stored in a serialized "ScriptedImporter" object class, which is suppose to be editor only. However that object class was not properly marked as editor only, on our side in native code, and because of that it is being pulled into the build data. When the player goes to load that object, it does not know how as the code to do so is not included with the native player thus throws the error "Could not produce class with ID".
     
    TextusGames and Elringus like this.
  8. Elringus

    Elringus

    Joined:
    Oct 3, 2012
    Posts:
    426
    Ah, it makes sense now, thanks a lot for the clarification!