Advice regarding DLL design

[humble_learner]

Hi,

We have a requirement where the back end processing logic is in C++. There are two front ends :
1. The GUI front end is to be developed using C# .NET
2. The Command Line front end is to be developed using C++

The backend engine is in pure C++.
Complex entities are being passed from the front end to the back end.
Considering that handling differs with respect to marshalling, is it normal to design a single consistent DLL for the backend irrespective of the type of front end (C#, C++).
As we need to pass pointers to complex data types (Classes with strings, characters, integers etc.) is it ok to use the same DLL in the back end considering issues with marshalling for the C# front end.

Or are two separate DLLs with separate signatures for the each of the C# based front and C++ based front end a safer approach ?

[darwen]

Have you thought about making your native C++ back-end dll a COM dll ?

Then both C++ and C# can interface with it without the need for separate interfacing dlls.

Darwen.

[boudino]

The C++ backend is already done, or you are creating it too? Than you can consider to develop it in .NET in C++/CLI (managed C++) as a common assembly, which you can easily reference from C#.

[humble_learner]

Hi Darwen,

Thanks for that point regarding COM. We do not have people having worked on creating COM unmanaged DLLs and hence did not think of that idea. How much of a work do you think that entails to convert a normal DLL (DLLEXPORT constructs) to a COM DLL. Can you access memory of managed class data types from the native unmanaged code through a COM interface or do you need to perform unmanaged memory alloc using CoTaskAlloc etc. ? We have done CoTaskAlloc and related methods to pass pointers to structures to the backend DLL for accessing data.

Hi Boudino,
The DLL is very much complete and in place. We did not go for C++/CLI because the code needs to be as portable as possible (ANSI ISO C++) as it is needed to run on Unix and Unix-like environments too.

Thanks

[Mutant_Fruit]

Someone with more experience can correct me if this is wrong, but C# can call native C++ functions which have been exported as 'extern C'. Then you can use the standard P/Invoke mechanism to access everything in the library.

If that isn't true, you could always create a really simple wrapper API in pure C which can definitely be invoked from C#. There's no need for COM at all if you go this route, and it'd probably be easier in the long run as you only need one backend lib which can be executed from C, C++, C# and whatever else.

[boudino]

As far as I know, you are completely true.

[Arjay]

If you need to pass a C++ class styled object, you'll need to use COM.

If a C-style dll interface is okay, then you can get by with PInvoke.

[diehardii]

If you are essentially passing around information, you can easily pass structs into a c++ dll. You have to watch the packing of the struct, and use IntPtrs to pass around the information. You can see an example of this in the code at
stochfit.sourceforge.net. Look at the setting.cs and the settings.h files. They must correspond <bold>exactly</bold> or things will go wrong at the point they diverge. The code is a bit of a mess right now, as its undergoing an overhaul. If you wish to update arrays or pass information back and forth, you can pass them as PInvoke parameters. While you could technically do this in the struct, its kind of difficult.