Integrate C++ DLL with C# GUI asynchronously (design issue)

Question

This is more a design than an implementation question. I am aware of how to integrate a C++ DLL within a C# main app that acts as GUI. Believe me that I've read all other questions on similar topics, but none of them clearly answer my question, so here we go:

• I have a C++ DLL with a few functions that interact with an API to another system (black box for me). The function that connects to the API must be "alive" whilst the whole program is running, otherwise connection to the API is lost and everything becomes more difficult. So, bare in mind that if I call the "Connect" function in the DLL and then I return to C# code, the DLL code will be out of context (no longer under execution), and disconnection will occur (correct me if I'm wrong please).

• So far it seems that what I need is:

  a) Call the C++ DLL functions using P/Invoke as usual

  b) Design a mechanism that keeps the DLL function (including calls to other functions within the DLL running all the time)

  c) Each time the C++ DLL module has new fresh data, callback the C# and update all necessary data for presentation.

It seems easy, but I don't manage to make the design in a way that none of them gets stuck. I've tried using infinite loops in the C++ DLL side, but then the GUI gets stuck. If I just perform a call to the DLL every "x" seconds, then I'm polling too many unnecessary times and the GUI becomes slow and not elegant in the refreshing. Besides, having the GUI as the "master" and the DLL as the "slave" results in disconnections because of DLL stopping execution whilst in C# code context.

Don't be too hard with me guys, I know there must be some simple design issue that I am not considering, but I can't find out what is it. I am new on C#, not on C++.

Also, I would appreciate if you could suggest another solution for a case where refreshing data from the DLL side would be almost real time, just like reading instant speed of a vehicle in real time.

Answer 1

a) Call the C++ DLL functions using P/Invoke as usual

This indicates that the OP did not read all there is.

P/Invoke is fine as it goes, but for more complex scenarios, a C++/CLI layer is far more appropriate, especially when it comes to callbacks into .NET.

The rest of the question IMHO cannot be answered without further detail from the OP, so I'll leave it at that.

Answer 2

It's not at all clear what you're trying to accomplish, but fortunately it doesn't really matter, as the C# and C++ integration aspect really doesn't play into it with respect to managing your asynchronous function calls.

Whether you use DllImport, (PInvoke), C++/CLI or something else, it really doesn't matter, as the state of the DLL innards is preserved between function calls.

So, bare in mind that if I call the "Connect" function in the DLL and then I return to C# code, the DLL code will be out of context (no longer under execution), and disconnection will occur (correct me if I'm wrong please).

This is not true. Let's look at an example. Create a simple DLL:

int foo = 5;

extern "C"
{
    __declspec(dllexport) int GetFoo()
    {
        return foo;
    }

    __declspec(dllexport) void SetFoo(int f)
    {
        foo = f;
    }

    __declspec(dllexport) int GetFooSquared()
    {
        return foo * foo;
    }
}

Then let's create a C# app that access those functions:

class Program
{
    [DllImport("MyLibrary.dll")]
    static extern int GetFoo();
    [DllImport("MyLibrary.dll")]
    static extern void SetFoo(int b);
    [DllImport("MyLibrary.dll")]
    static extern int GetFooSquared();

    static void Main(string[] args)
    {
        Console.WriteLine("Get foo {0}", GetFoo());

        SetFoo(7);
        Console.WriteLine("Get foo {0}", GetFoo());
        Console.WriteLine("Get foo squared {0}", GetFooSquared());
    }
}

And if we run it, our foo variable in the dll will be modified, and the modified value will be preserved across function calls. When the C# library starts up, when the first call to MyLibrary.dll takes place, the library is loaded and its memory space stays loaded.

Running the example we get an expected output indicating state is preserved:

 Get foo 5
 Get foo 7
 Get foo squared 49

So, structure your design imagining how you'd do it if it was all in one language, C# or C++. Whatever design you come up with, the only modification you need to make it work is to cross the C#/C++ boundary. The options to do that is to write a C++/CLI class to map data structures back and forth, or to pipe everything across C style function calls, but those are not very difficult, and there's a variety of ways to make it work.

But ultimately you do not need any busy waiting loops or anything of that such because your DLL won't "disconnect" without you going through some serious hoops to make it do so intentionally.