Calling Managed Code From Unmanaged C

Question

So after about a day and a half with this I\'ve made zero progress.

I need to write a DLL in C that is used a plugin for an existing application. The DLL has to be c

Answer 1

The way I resolved this was simply having the C dll call cmd and execute a compile VB.NET executable and pipe it's output. Although this isn't wasn't a totally ideal solution it worked in this situation when all I required back was a single string.

Answer 2

You have a lot of options to do this but not all of them are trivial.

Mixed mode assembly

The first, and more easy way, to export managed code to a C client is to write your code using C++/CLI (or to write a wrapper using that language). You simply export the C functions you need as you would do in normal unmanaged code and inside their implementation you call the managed functions you need. Here on MSDN.

COM Interop

You export your managed classes as COM objects. From unmanaged code you'll see normal COM objects, take a look here.

Reverse P/Invoke

You can do it in different ways. The more simple one is to revert the point of view. If you have a VB.NET assembly (vbnet.dll) and a C library (purec.dll) the first thing you may imagine is to add a dependency to vbnet.dll in purec.dll. If you do it in this way you have to use COM or to make your application a .NET host. A more easy way is to revert: add a dependency to purec.dll in vbnet.dll (using P/Invoke). Your C interface will export a struct (for example) that can be filled with function pointers, you'll fill that struct in VB.NET (as delegates) and your C code will simply call them. Take a look here.

Other options

Native host: this is the hard way. Your native application will host the .NET application. It's long and complicated, I guess it's too much if you only need to export few functions. I post here just for reference: hosting overview on MSDN.
IPC. You can keep your application separated and each other can ignore how the other one is written. Simply define an interface and a channel to connect them (named pipes, shared memory or anything else, look here for a list). This works if your VB.NET application is a service or it's hosted by a running application, if it simply exports few functions you can't do it.

Answer 3

Unless this is an existing vb.net dll (business layer) that you use everywhere, I'd probably recommend against using it in a C application.

There are various ways to communicate with MSSQL from C. Either by a native driver or ODBC, etc.