Develop Reference

How to give a C# DLL a C-compliant interface?

A third-party app I have can call extension DLLs if they have C-compliant interfaces as described below.
I would like the third-party app to call my C# DLL, since I would rather write in C# than C. (Maybe my other choice would be to write a C DLL wrapper to call my C# DLL, which is an extra step that I might not get right).
I've searched the net and SO but haven't found (or recognized) a good match to my question.
The best suggestion seemed to be this special marshalling declarations in the C# code here: Calling a C# DLL from C; linking problems
Is it possible to write a C# DLL that has a C-compliant interface like the one below? If so, could someone tell me what I have to do or point me to some documentation?
The third-party app documentation says, "The DLL function must be a PASCAL function that takes a single LPCSTR (long pointer to a constant string) argument. C or C++ DLL functions called must have prototypes equivalent to:
extern "C" __declspec(dllexport) void __stdcall fn(LPCTSTR szParam );

Take a look at this article: https://www.codeproject.com/Articles/12512/Using-the-CDECL-calling-convention-in-C-changing
It discusses a different problem (opposite to yours) but also explains the linkage of C# functions - by default C# uses __stdcall (and it cannot be overridden). This means your third party app should be able to call the C# function as it stands. Have you tried it? Did you get any errors?

Making A imported(DllImport) C++ DLL thread safe for C#

I was wondering what the "requirements" for a C++ dll being imported into C# using DllImport, to make it completely thread safe given the functions in the C++ Dll are very basic.

There's no default protection, if that's what you're asking - it's as if you called the function from any other language.
If you need thread-safety, you'll need to make your own wrapper class that provides that safety, and make sure your code doesn't bypass that (just make the DllImported methods private within the wrapper class).

Calling C# code from unmanaged C++?

In Mono you can pass a delegate from C# to a C++ function which takes in the delegate as a function pointer. Can this be done in C# on Windows for example where you can compile a native C++ unmanaged library, link it against a C# project and get a C++ function to invoke a C# function via a function pointer which C# passed to it as a delegate?

Define a delegate in .NET, and then pass that to your unmanaged code. The CLR will expose the delegate as a function pointer which you can call from your unmanaged code.
The interop layer does not know how to handle references in C++. So You need to expose the object as a pointer, not a reference. Additionally, .NET doesn't know what a C++
object is (it's not the same as System.Object). That will need to be passed
as an IntPtr, and I don't think there is much you can do with it in .NET.
C++ callbacks:
typedef void (*CBFUNC1)(unsigned int, const char*, object&);
typedef object* (*CBFUNC2)(object*, struct _mystruct* );
C# signatures for the delegates would be
delegate void CbFunc1(uint param1, [MarshalAs(UnmanagedType.LPStr)] string
param2, IntPtr param3);
delegate IntPtr CbFunc2(IntPtr param1, ref _mystruct param2);

One option you have is to use C++/CLI to call into the C# code. If your C++ code must stay unmanaged (native), then you should wrap your C# code in a COM component and use it from your C++ code.

This obviously can be done - all CLR hosts are native applications to start with. Your options:
in managed application call your native DLL (PInvoke)
call managed COM object (as Dan suggested)
host CLR yourself - sample

You are looking for Marshal.GetFunctionPointerForDelegate().

Rohit's answer is right, but there are lots more gotcha's on the path depending on whether you're calling back immediately (C# calls C++ which calls back C#) or if you want to call back repeatedly (C# calls C++ and after returning calls back one or more times later to C#).
i wrote this example from the perspective of Unity/C# and C/C++/Objective-C interop, but you may find some of the comments and code-snippets useful no matter where you are doing C#/C interop.
in particular make sure that you're propertly retaining/holding any delegates you pass from C#/managed to C/unmanaged code if the C/unmanaged code might be calling back at a different time.

How can I call a function of a C++ DLL that accepts a parameter of type stringstream from C#?

I want to import an unmanaged C++ DLL and call a function that takes stringstream as a parameter. In C#, there is no stringstream class, so can anyone tell me how to call such a function from a C# program?

You should not expose templated objects via a DLL, period.
Templated objects (e.g. almost everything in std::) become inlined. So in this way, your DLL gets its own private copy of the implementation. The module calling your DLL will also get its own private implementation of stringstream. Passing between them means you are inadvertently weaving two unrelated implementations together. For many projects, if you are using the exact same build settings, it's probably no problem.
But even if you use the same compiler, and mix a release DLL with a debug EXE, you will find stack / heap corruption and other harder-to-find problems.
And that's only using your DLL from another unmanaged C++ exe/dll. Crossing then the lines to .NET is even more of a problem.
The solution is to change your DLL's interface to something that plays friendly across DLL bounds. Either COM (you could use IStream for example), or just a C-style interface like the winapi.

If you can modify the C++ dll, export a plain string version. Otherwise you have to build a managed C++ wrapper project, import the other C++ dll, export it as a managed function, and call that from your C# code. C++ interop really sucks.

I'm afraid that you're going to have to create your own StringStream class in C# in order to be able to consume the functions exported from that DLL. As you mentioned, the .NET Framework doesn't provide any similar class out of the box.
The easiest way is probably to wrap the StringBuilder class provided by the .NET Framework such that it can function as a stream. See this blog post for a further explanation and some sample code.
A similar question was also answered in MSDN Magazine: http://msdn.microsoft.com/en-us/magazine/cc163768.aspx. You might find some of the hints and/or sample code given there useful.

You are trying to bind native C++ code to managed code in C#. Best way of doing that in general is to introduce middle layer in managed C++ that will provide interface to calls from C#.

Create an Wrapper dll in c, or c++ that exposes an friendly call to that function. It's the better way.
for example an
BOOL getString(TCHAR * myreturnString, DWORD *size);

Marshalling reference-types from C++ to C#

I want to invoke the following C++ function (exported by a DLL) from C#:
void createVm(
const jace::VmLoader& loader,
const jace::OptionList& options,
bool ignoreUnrecognized = true );
I've found documentation for marshaling primitives from C++ to C# but I'm not sure how to handle reference-types or non-pritmive types such as VmLoader or OptionList (both of which are classes). I'm trying to wrap a C++ API with a C# layer, delegating to the underlying C++ code for the actual method implementation.
Any ideas?

AFAIK, PInvoking into a function with C++ constructs is not a supported operation. You could probably get it to work but I think you'll find problems.
What is supported is writing a simple C wrapper function which calls into your C++ function. PInvoke into the wrapper function instead and that will do the trick.

Assuming the c++ DLL correctly exports the types being passed by reference, you could right a light weight managed C++ wrapper that calls the dll. With managed c++ you can call native C/C++ libs and dlls directly while still exporting a managed interface from the resulting assemblies. Other .Net languages can call the managed interface just like they would any other assembly. It's a bit of extra overhead, but's is can be the quickest way to get it done.