I dont want to "export" anything directly. The only functionality needed in managed code is the ability to define custom controls and do resource binding.
The renderer shouldnt care about where the data is coming from, because at that point its basically a part of the engine itself.
As i said before, think about a hybrid use case, where high performance game code is written in c++ but you still have the option to load managed plugins and raw c# files that can be hot reloaded at runtime for faster iteration, which is perfect for ui related code.
My initial believe was that the managed sdk just wraps around the noesis.dll like the native code does, and just invokes functions in there, which should technically easily allow access to the same dll in the same process that was already loaded by native code.
This would enable the end user to just drop in the noesis engine plugin, and use it both in managed as well as native code.
Having the renderer it self be also in managed code doesnt really make any sense from both a performance and portability standpoint since its coded against platform agnostic structures of the engine renderer which enables it to basically run on any system or rendering api the engine runs on. Same goes for the file/font/texture/xaml providers.
This works already perfectly fine for native plugins that just link against the noesis lib and do nothing else but calling the registration functions.
My "naive" solution would be to simply pass the noesis instance pointer that somehow must be created internally when init is called to the managed code and have it run all the reflection and component creation logic on that.
This would also enable it do be used from whatever other scripting language you might bind against, be it lua or javascript.
(I made a diagram)
