Custom resources won't work with Mono, leads to constant crashes

[mthreis]

Adding custom "data-container" resources (classes that inherit from Resource) will not work with Mono. Gets the editor to crash constantly.

Steps to reproduce:

• Create a class that inherit from Resource: public class MyResource : Godot.Resource
• Add some [Export] fields to the class (such as string name;)
• Create a Resource (via Inspector window), save it, and set MyResource as its script
• Get a script to load the resource and access the exported fields using:

var res = GD.Load("res://my_resource.tres") as MyResource;
GD.Print(res.name);

• See your project constantly crash until you delete my_resource.tres and MyResource.cs.

The steps above will work just fine if you use GDScript.

[aaronfranke]

Is this issue still reproducible in the latest master? There have recently been some changes to Mono/C# class extensions which may have helped.

[nhold]

I can confirm on fa02453 that this crash no longer happens, however types don't show up in the Resource popup menu, so I decided to take a stab at it. It looks like GDScript somehow registers each parsed type to the ClassDB (Then handles exporting in it's info) I guess that's the way to go for Mono. Does anyone have any insights?

Essentially I think we can update the ClassDB after a successful build from the project assembly (I wrote some quick classes to iterate over all classes \ get all classes that inherit type using the raw Mono API and some of the mono module API).

EDIT: Okay after searching for a while I believe I am actually looking to liaison with ScriptServer, when it inits it looks through the "_global_script_classes" array.

[nhold]

Okay, I believe whatever writes to filesystem_cache4 is used to add to the global script classes. It seems the mono module scripts don't get their script_class_name \ script_class_extends written to e.g:

new_script.gd::GDScript::1544569977::0::1::new_script<>Resource<>::
TestResource.cs::CSharpScript::1544455074::0::1::<><>::

[KoBeWi]

Can anyone still reproduce this bug in Godot 3.2.1 or any later release (e.g. 3.2.2-beta4)?

If yes, please ensure that an up-to-date Minimal Reproduction Project (MRP) is included in this report (a MRP is a zipped Godot project with the minimal elements necessary to reliably trigger the bug). You can upload ZIP files in an issue comment with a drag and drop.

[KoBeWi]

Closing due to lack of update. Please comment if you can still reproduce this issue in the latest stable version of Godot.