It adds features to the editor, not to the engine.
That would change if we figured out how to make a C# and C-linkaged fat-binary dynamic library.
I've been reading about it. The usual thing to do is to use C++/CLI. Which sounds fine on Windows. Not so much anywhere else.
Radnen, when you make a DLL with C#, what kind of intermediate object files you get? Is it a similar process to the old Windows compilers before .NET, and the C/C++ compilers?
It's a slightly unnecessary idea, though, you could just write the a library and have two separate plugins for the engine and editor that both call the library. But it would just be so incredibly cool and streamlined to have a single DLL that works as both, and is being called from both C/C++ and C#.
Yeah, the unified DLL/SO thing is really an aesthetic, and partially a convenience. But if it worked, it would also really impress folks who knew what they were looking at--me included! Plus, I'm, not sure anyone else has done just exactly what we're talking about, and this the perfect use for it.
About how I am hoping to do it, I'm hoping that object files generated by MSVC are the same format as the ones made by the MS C# .NET compiler at some point along the way, and one or the other linker (if they are different) could be used to link both the TS plugin's object files and the editor's plugin's object files together and make a single binary. I highly doubt that would work, but it is a good thing to try first I think. The same might work (and I actually suspect will work better) using LLVM or GCC on Linux and Mac.
C:\spherestudio\Sphere.Plugins>csc /target:module /r:"C:\GitHub\spherestudio\Sphere Editor\Libs\dockpanelsuite\WeifenLuo.WinFormsUI.Docking.dll" IPlugin.cs IPluginHost.cs Properties\AssemblyInfo.cs
C:\turbospheresrc\plugins\getkeystring>cl /c /MD getkeystring.cpp
C:\turbospheresrc\plugins\getkeystring>link /LTCG /DLL /ASSEMBLYMODULE:IPlugin.netmodule "../../lib/v8.lib" /OUT:fatplugin.dll getkeystring.obj IPlugin.netmodule
The reason I could implement the plugin system so fast was that I unloaded all the heavy lifting onto the plugins, the engine does very little now. It mainly starts up a V8 context, compiles scripts (which could easily be a plugin's responsibility), and intializes plugins. To change that, I would have pretty much abstract away the interface to JS. Which is an immense undertaking, and begins to tempt that black hole of total extensibility.
It would be another matter to have it call common routines from both sides (if the C# side is really working correctly at all). But I for one think this is better already than having two separate plugin files for a single purpose.