Is there a way to use a C++ API in C#?

Question

I want to code a little program that takes in head tracking data and moves a 3D object accordingly on the screen. To achieve this I found a software called opentrack that has a C++ API. The problem is that any game dev environments I know / have a way to access use C# as the language.

I'm very confortable with C# and used to be comfortable with C++ and C a while back, and could easily get back into it if a solution required it.

This is a silly little personal project, but one I'm passionate about and would love to solve, so any help in resolving this would be appreciated. Thanks!

UPDATE:

Wow, that's an amazing amount and quality of responses, I would like to deeply thank everybody who contributed!

Answer 1

There are various ways to call native code from c#

1. P/Invoke - allows c-style method calls directly from c# code. If the API does not expose c-style (i.e. extern C) functions you will need a wrapper that does this. If the API uses any kind of objects this will probably be an painful approach.
2. C++/CLI - This allows you to use .Net types in a c++ project. So you would create a wrapper c++ project that interfaces with the opentrack API, and is called from your regular c# code. This looks like a nice guide on how to do this.. An advantage of this is that it allows you to write wrappers around objects to provide a object oriented API.

Answer 2

For object-oriented APIs, you should consider using a tool which generates a .NET wrapper automatically. Check out CppSharp over on GitHub. Not everything will work automatically but if you are going to wrap 100 classes, it makes sense to generate the bulk of the code needed for interoperation.

Whether you are just wrapping a few classes or en entire SDK and whether you write your own C++/CLI interoperability code, it is always good practice to have the C++/CLI code in a separate assembly since you will deal with unmanaged code and unmanaged code debugging which you WANT to centralize in a single component.

Answer 3

You sure can, and I've done so on both Windows and Mac using .NET Core 3.1, but it will most likely work with .NET Framework as well with minimal modification.

The method I used is called DllImport and is describe here: https://docs.microsoft.com/en-us/dotnet/api/system.runtime.interopservices.dllimportattribute?view=netframework-4.8#examples

Below is an example from my own C# code.

    class Program
    {
        // This is where you declare the functions from the C file that you want to use. The filename is a relative path to the file containing the `Program`
        [DllImport("libHello.dll")]
        static extern string say_hello(byte[] buffer);

        static void Main()
        {
             var buffer = new byte[1024]; // create byte buffer
             say_hello(buffer) // call the C function
             Console.WriteLine(Encoding.ASCII.GetString(buffer)) // 'hello'
        }

The most important part is to ensure that the C library that you're using is compiled for the platform you're running on.

If you'll be passing large data back to the C# program, you might think about using a library called cJSON and passing a C struct as JSON to the the buffer, that you can then deserialize into C# class instances. That's how I did it, and it really keeps the C complexity down since you don't really need to worry about freeing heap space from the C# code.

Please note that I accomplished the above using non-Microsoft tooling for C development (of course I did use .NET Core and CLI for the C# stuff). I don't particularly like Visual Studio and Visual C++ and that is my own bias.

Answer 4

SWIG - Simplified Wrapper and Generator is the only sane way to do stuff like this. It looks like CppSharp mentioned by @helb is built on top of it. So go for CppSharp, there is no need to reinvent the wheel.

I am pointing SWIG out, not just for completeness but because in some cases it may be simpler. I have no experience with CppSharp though.

As for C++/CLI, I won't start a new project with it. Not even a "Hello World" project! I am saying this as someone who wasted a lifetime on Microsoft Technologies like WCF, WPF, WinForms, OData, and more. I may be wrong but I just won't bet a stone on it. Yes, I have read this and I am still not convinced it will make it to the final wrap up of .Net.

Answer 5

Having been down the road of C++/CLI and the pitfalls of having managed code marry up well with unmanaged code I can't recommend enough avoiding the approach of having C++ and C# binaries directly linked. Principally because of the garbage collection, it's hard to ensure a C# object is destroyed, in the sense that it is really destroyed, and will not interact with C++ objects that you can guarantee have been destructed, that being the virtue of an unmanaged language.

What you may find less problematic, albeit with its own overheads, is to have a process for each language runtime and then to setup a websocket protocol between them. For example, you could use Websocket4Net for C# and Beast for C++.