Adding a `Bonsai.Editor.Scripting` node to an unsaved workflow results in obnoxious behavior

[PathogenDavid]

If you add a Bonsai.Editor.Scripting node to a workflow, you end up in a situation where you cannot edit the C# Script because there's nowhere for the Extensions folder to go:

However if you attempt to follow the instructions and save your workflow, you'll find that cannot save because the node is "non-public":

This is pretty obnoxious and I'm not confident the error would actually help the average user realize what's wrong. (Although perhaps anyone using C# scripting is not an average user.)

IMO Bonsai should either A) tolerate saving workflows with the placeholder nodes or B) prompt to save the workflow when adding the node.

Option A seems like the right solution to me, but I'm not sure why it's prohibited to save workflows with non-public types in the first place. (Seems like it should be a compilation error to me.)

[banchan86]

I ran into this recently and yes it was bugging the hell out of me haha

[glopesdev]

@PathogenDavid Indeed this behavior has been there for a while and is pretty obnoxious. The XmlSerializer does require all types to be public, which is where the limitation comes from. I left the C# scripting nodes internal to the editor as I didn't want to have people to deal with partially broken workflows saved with these placeholder nodes.

We could make them public which would be the same as taking option A). I have a third option which is to simply generate the types on double clicking the node anyway, regardless of whether the editor was opened and saved. The relevant logic is here: https://github.com/bonsai-rx/bonsai/blob/729d503e137945d21e3ed3bb7a3deb331674cc78/Bonsai.Editor/Scripting/ScriptComponentEditor.cs#L205