Thanks for your reply.
"Porting the meat to C#" is not really feasible. The library in question is mostly a (complex) wrapper around a set of rather complex and complicated modules mostly written in C, written for a different product with roughly a million LOC, which cannot be ported to C# for several reasons:
- the code has strict realtime requirements
- we need to support embedded platforms like QNX, eCos, VxWorks or Real Time Linux
- we need to support sitting inside the kernel of Windows as a driver (due to real time requirements)
- the code is required to run on "bare metal" with no real OS at all
- our customers use more than 12 different families of CPUs, including strange DSPs which don't even have a "byte" as datatype.
Thus, "porting the meat" effectively means maintaining the code in parallel, duplicating the work and thus higher risk of bugs etc
That's why we interface it from C# using C++/CLI on "desktop .NET".
When going to .NET Core, we wanted to avoid the hassle to "flatten" the nice object oriented interface to a plain C interface just to rebuild a nice object oriented .NET interface on top of it in C#. But it seems we need to go that way...