Error exporting a Mono project with an editor plugin

[git2013vb]

Godot version

3.4.beta3 mono

System information

debian 10

Issue description

When I try to export I have this error

addons/editorsettings/plugin.cs(5,23): The type or namespace name 'EditorPlugin' could not be found (are you missing a using directive or an assembly reference?)

the error screenshot:

While i can compile and run it without problems.
Here other errors in console:
addons/editorsettings/plugin.cs(10,26): 'plugin._Ready()': no suitable method found to override
addons/editorsettings/plugin.cs(18,26): 'plugin.EnablePlugin()': no suitable method found to override

Steps to reproduce

this is my plugin:

using Godot;
using DesertEdge.Utils;

[Tool]
public class plugin : EditorPlugin
{
    private const string PORT = "7010";
    private const string REMOTE_PORT = "network/debug/remote_port";

    public override void _Ready()
    {
        Log.Print(Log.DEBUG, "Plugin Editor Settings ready");
        EditorSettings editorSettings = this.GetEditorInterface().GetEditorSettings();
        editorSettings.Set(REMOTE_PORT, PORT);
        Log.Print(Log.DEBUG, editorSettings.Get(REMOTE_PORT));
    }

    public override void EnablePlugin()
    {
        EditorSettings editorSettings = this.GetEditorInterface().GetEditorSettings();
        Log.Print(Log.DEBUG, editorSettings.Get(REMOTE_PORT));
        editorSettings.Set(REMOTE_PORT, PORT);
    }
}

Minimal reproduction project

na

[Atlinx]

I think EditorPlugins are only supposed to run in the editor. GDScript plugins also have this behavior, which leads me to believe that this is intentional.

[raulsntos]

Yes, access to the editor API must be surrounded with #if TOOLS as explained in #41196

[git2013vb]

I think EditorPlugins are only supposed to run in the editor. GDScript plugins also have this behavior, which leads me to believe that this is intentional.

It make sense ofc.. But still sometime a EditorPlugin is necessary to run. In my case I use to export the current project and run it outside editor in order to make free some hw resources while working in connected projects. Otherwise I have to pretend the project is finished and run it somewhere else. If I'm not mistaken there was an issue/discussion where mentioned the editor log port to be related to the project and not to the game engine.

[Atlinx]

I'm not really sure what you mean by "hw resources" and "editor log ports" but I normally keep my plugin logic out of editor-related classes such as EditorPlugin. Instead, my EditorPlugin class contains instances of classes that control the plugin logic. I can then just use those classes directly outside of the editor as well. Maybe you could try something similar to get your plugin working in standalone builds?

[git2013vb]

I'm not really sure what you mean by "hw resources" and "editor log ports" but I normally keep my plugin logic out of editor-related classes such as EditorPlugin. Instead, my EditorPlugin class contains instances of classes that control the plugin logic. I can then just use those classes directly outside of the editor as well. Maybe you could try something similar to get your plugin working in standalone builds?

For "hw" I mean "hardware" :).. and for "editor log ports" I mean this one (from code before posted) :private const string REMOTE_PORT = "network/debug/remote_port";
See #37687 and godotengine/godot-proposals#578
How can your suggestion fit my problem?
Thanks :)

[raulsntos]

Closing as working as intended. Godot's Editor APIs (such as the EditorPlugin type) are not available in exported projects since there's no Editor.

Access to Editor APIs must be surrounded with #if TOOLS to prevent build errors when exporting the game, like so:

#if TOOLS
using Godot;

[Tool]
public class SomeEditorPlugin : EditorPlugin
{
	// Code here...
}
#endif

The use of the define constant TOOLS can be seen in the documentation for making plugins (in the C# code example).