C# Variable Exports get lost when the ".godot" folder is deleted

[HeySora]

Godot version

4.2.rc2

System information

Godot v4.2.rc2.mono - macOS 14.2.0 - Vulkan (Forward+) - integrated Apple M1 Pro - Apple M1 Pro (10 Threads)

Issue description

In a minimal project with a single C# export, despite the reference being stored in the .tscn file, it gets lost when the .godot folder is deleted.
Specifically: When both .godot/exported and .godot/mono are deleted, the issue appears.

It means that this issue will appear when simply storing a Godot project on a Git repo, and cloning that repo to another machine. That machine will be producing broken builds.

When starting the Godot editor in such a state, the variable export will not even appear at first. Hitting the "Run Project" button will make it appear (and the reference looks intact), but the internal state of the editor will still be broken in a variety of ways :

• Clicking on Project > Reload Current Project will make the variable export be unassigned.
• Saving the scene will make every reference be NodePath("").
• Any exported build will still be broken.

This issue has succesfully been succesfully reproduced on three separate machines (Windows + macOS, x86 + ARM):

• Godot v4.2.rc2.mono - macOS 14.2.0 - Vulkan (Forward+) - integrated Apple M1 Pro - Apple M1 Pro (10 Threads)
• Godot v4.2.rc2.mono - Windows 10.0.19045 - Vulkan (Forward+) - integrated Intel(R) Iris(R) Xe Graphics (Intel Corporation; 30.0.101.1404) - 11th Gen Intel(R) Core(TM) i7-1165G7 @ 2.80GHz (8 Threads)
• Godot v4.2.rc2.mono - macOS 13.4.1 - Vulkan (Forward+) - integrated Intel(R) Iris(TM) Plus Graphics - Intel(R) Core(TM) i5-1030NG7 CPU @ 1.10GHz (8 Threads)

This issue also happens in Godot v4.2.rc1, and broken builds stay broken no matter which platform it is exported to.

This issue is a problem since every reference from every scene needs to be restored for every machine running the project, unless .godot/exported is actually kept as an exclusion in the .gitignore file.

Steps to reproduce

The attached minimal reproduction project only contains a single 2D scene with a Label and a script attached to the root node. That script changes the label's contents from "default text" to "C# actually works"

(As per this repo's rules, the .godot folder has not been included, which means that the project will be broken out of the box.)

With the project downloaded as-is, the C# variable export will not be visible in the inspector tab, while focusing the root node.

Hitting "Run Project" will make the exported variable show up, and visually pointing to the Label in the scene; but the running project will still show "default text", as if the C# script did not work. No errors are shown in the Output nor Debugger.

After that, exporting the project will produce a broken build, with the variable export not being actually filled.

Clicking on Project > Reload Current Project will now show that the reference has really been lost.

From that point, re-assigning the label again and saving will fix the project, and exported builds will be functional as expected.

However, closing the editor, and deleting the entire .godot folder (OR only deleting .godot/exported and .godot/mono), and re-opening the project, will restore it into a broken state. Exported builds will not work, and saving a scene will erase every export references to NodePath(""), as explained above in the issue description above.

Minimal reproduction project

TestExport.zip

[Flavelius]

I would guess that this is related to the assembly not existing yet. If that's the case then building the project and restarting godot without saving might fix it. And if that fixes it, it might make sense to add initialization logic to the editor that does this once if it detects the .godot folder as not existing on startup.

[akien-mga]

Is this reproducible in 4.1.x too?

[HeySora]

Is this reproducible in 4.1.x too?

Yes, I just reproduced it in 4.1.3, although the visual glitch is slightly different.

System Info: Godot v4.1.3.stable.mono - macOS 14.2.0 - Vulkan (Forward+) - integrated Apple M1 Pro - Apple M1 Pro (10 Threads)

Differences:

• Reloading the current project shows an empty entry in the exported variable, instead of the standard "Assign..." like in 4.2
  
• Saving the scene in this state throws a C++ error, which did not happen in 4.2
  

Similarities:

• The NodePath present in the .tscn file still is empty just like 4.2 though:
  
• Exported builds are identically broken, in that state where the editor still shows the label as being successfully assigned to the exported variable.
  

[paulloz]

Either I don't understand the reproduction, or it doesn't reproduce on Windows (10) with 4.2.stable.

Edit: Indeed, just me being thick. 100% reproducible. This does not happen when one clicks "build" before clicking "run".

[paulloz]

Massive issue with how we manage data when we don't have build data to base scene serialization on.

Basically what #60597 fixes for GDExtension. It should be possible to keep property values in a placeholder data structure and use those as fallback for serialization when CSharpScript.valid == false, or to leverage the MissingNode type introduced in the linked PR.

[nikitalita]

You may want to take a look at #86600