Not sure to follow here, but something important, you cannot mix both SDKs, we don't support exporting C++ code in the C# SDK, is that what you are trying to achieve?

Exactly that was my intent. To allow for a hybrid approach. Otherwise it would be impossible to integrate noesis properly into the engine while still allowing to do ui in managed code.
A shame this doesnt work :(

What do you want to export in c++ to the managed SDK? I assume it is the renderer you implemented right?

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)

You are raising good points in your last message. Thanks also for the cool diagram.

The problem right now is that our C# SDK is using a different Noesis.dll than the one found in the C++ SDK. Noesis.dll in C# SDK is not exporting classes at all, only extern 'C' functions are being exported to be used by C# wrappers. This is being done for efficiency (size efficiency) and I am not sure if there are more reasons (for example, Unity doesn't need it at all), I don't remember right now.

With access to the source code you could create a scenario like the one described in your diagram (I think a few companies are already exploring that path). We should find time to analyze this.

Thanks for the nice answer!
Yeah, i looked at the managed library with dot peek and realized that it did quite a bit of the work by itself.
When the need arises i will manually expose functionality for now!