I am starting work on a new project where the core product is a Software Library. There is existing code we will be wrapping, written in C++ because it is very numerically intensive; we own and compile this core code.
I believe we will have two prominent client types:
1. App written in C++, probably MFC
2. App written in C#.NET.
The Question: In order to offer an “ideal” interface to both these client types, what technology do we use? For example, we could offer two interfaces, one using C/C++ functions and callbacks for the C++ clients, and the other using C#.NET for the C# clients? Also, in principle, could this be done nicely in one DLL, or will we want two (or more)?
Other info… Client apps are embedded, not a desktop or laptop; assume any UI is not Windows-based. Also we will have to compile and test for both 32-bit and 64-bit, probably C++ on 32-bit and C# on 64-bit.
My apologies here — I realize this question may have been asked and answered previously, but if so, I was not able to find it.
Interesting question, I’m looking forward to other answers.
One possible solution, if probably not the best: If your library code follows object-oriented practices, you could write the core functionality in C++ and then provide separate COM wrapper classes around the core classes (also in C++). This would allow you to use your library components from .NET via COM interop. I don’t know how efficient that would be — I suspect performance should generally be fine —, and COM has some obvious drawbacks (no generics, for example), so that may not be the optimal solution.
If your library is not object-oriented, you can still call single functions exported from any DLL in .NET using P/Invoke… if you go down this route, it’s likely that you’ll end up with a C# wrapper around your C++ DLL.