Search Issue Tracker

Third Party Issue



Found in





Issue ID




Unity does not execute code weavers when the project is opened for the first time



How to reproduce:
1. Download user attached project ""
2. Inside the project folder, delete the "Library" folder
3. Open the project
4. Enter Scene "SampleScene"
5. In the Hierarchy window, click on a Game Object "GameObject"
6. In the Inspector window, observe the "Tester" Component

Expected result: Both "Basic" and "TestNum" fields are shown
Actual result: Only the "Basic" field is shown

Reproducible with: 2020.2.0b3 2020.3.13f1, 2020.3.15f2, 2021.1.16f1
Not reproducible with: 2019.4.29f1, 2020.2.0b2
Can't test: 2021.2.0b6, 2022.1.0a5 (Console error: "An infinite import loop has been detected. The following Assets were imported multiple times, but no changes to them have been detected. Please check if any custom code is trying to import them")

-By invoking ReloadAssemblies (by reopening a project, modifying a script) the "TestNum" field appears
-If we do a build of the project, the built application will crash upon launching
-If we do a build after reopening the project, the built will not crash

  1. Resolution Note (2022.1.X):

    The issue has been confirmed to come from
    Explanation here:
    - When loading a project containing user code, we have 2 domain reloads: the inital one that loads unity own assembly, compile the code and trigger the second reload that contains compiled scripts
    - Before 2020.3 we used to load pre-compiled assemblies during the first domain reload: thus the second domain reload happened after foddy integration initialization, picking up the changes it injected.
    - Starting with 2020.3, the ordering did change a little bit, to prevent issues where pre-compiled assemblies can depend on script code to execute correctly
    - AssetDatabase does not track assemblies from script compilation, only the source files, but the changes produced by foddy only modify the compiled assemblies.
    - Now that the initialization occur on the 2nd reload, there is no other change, or other system triggering a domain reload picking up the changes brought by Foddy: the assemblies are weaved, but not reloaded.

    To fix that, instead of triggering an ADB refresh, Foddy integration package should trigger a domain reload using
    We opened a PR to help fixing the issue here:

Add comment

Log in to post comment

All about bugs

View bugs we have successfully reproduced, and vote for the bugs you want to see fixed most urgently.