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 compiled by the Visual Studio 2008 compiler with the following options

cl -DNT40 -DPOMDLL -DCRTAPI1=_cdecl -DCRTAPI2=cdecl -D_WIN32 -DWIN32 -DWIN32_LEA N_AND_MEAN -DWNT -DBYPASS_FLEX -D_INTEL=1 -DIPLIB=none -I. -I"C:\plm\2T-RAC\TcEx press53\include" -I"C:\Program Files (x86)\Microsoft Visual Studio 8\VC\include" -c -nologo -EHsc -W1 -Ox -Oy- -MD C:\mydir\myDll.c

It's then linked to applications library's.

What it actually needs to do and what's causing me the issues is that within one of the methods it needs to pull data from a sql server 2008 r2.

From what I've seen today you wouldn't be able to do this directly in C as SQL Server past 2005 is designed to communicate with CLR languages( C#, C++, VB.Net).

It was suggested that I handle all the database communication with a VB.Net dll and then call said function from within the C dll.

Most of what I've found on the topic of calling managed dll's from unmanaged code has talked about pinvoke or com wrappers and mainly from the perspective of c++.

I have zero experience with COM or any mentioned techniques so if anyone could help out it would be much appreciated.

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

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.

Answer 3

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.