Yes it’s a bit complex, here eqFreeHaskellString, is an exported haskell function which call free. Documentation says I could use the normal C free, but in case of change, it’s safe. The problem is you can’t give simply malloc’ed data to .net. It use another heap, different from the C one, and this is the role of ::CoTaskMemAlloc to allocate data in the good heap. If you don’t do this, the function will crash on return. CoTaskMemAlloc is provided by the Ole32 library, so you must have a copy of it around to link against it.

Ok now the DLL is ready, there’s only the easy part on .net.

The .net side of things

In .net we want to use the DllImport attribute to neatly map haskell function. It’s easy, two lines of code for each function (don’t forget the begin & end runtime you must provide in the DLL (see GHC user guide).

        [DllImport("foo.dll", CharSet = CharSet.Unicode)]
        public static extern string myExportedFunction(string in);

Right? WRONG

It was too easy isn’t it?
Shit happens here.

For an unknown reason you can’t simply load the library this way. After some tests in C++, the loader don’t seem to find the imports in the DLL, the only way to do it seems to use the LoadLibrary and GetProcAdress to retrieve the functions adress manually and then call it. It’s pretty straightforward in C++, but not so in .net, so here’s a sample :

using System.Runtime.InteropServices;
/* other code blah blah blah */
[DllImport("kernel32.dll")]
private static extern IntPtr LoadLibrary(string fileName);


[DllImport("kernel32.dll", CharSet = CharSet.Ansi, ExactSpelling = true, SetLastError = true)]
public static extern IntPtr GetProcAddress(IntPtr hModule, string procName);

[return: MarshalAs(UnmanagedType.LPWStr)]
private delegate String Evaluator([MarshalAs(UnmanagedType.LPWStr)][In] String input);

Evaluator ExportedFunc;

Just few type declarations, as you can see, we introduce a new delegate type matching the type of the Dll function. MarshalAs attributes are important to keep unicode information.

IntPtr formulaLib = LoadLibrary("myNice.dll");


if (formulaLib == IntPtr.Zero)
    throw new DllNotFoundException("myNice.dll");

IntPtr exportedFunc = GetProcAddress(formulaLib, "myExportedFunction");

if (exportedFunc == IntPtr.Zero)
    throw new MyNiceException("The dll doesn't export the good functions");

ExportedFunc = (Evaluator)Marshal.GetDelegateForFunctionPointer(exportedFunc, typeof(Evaluator));

And that’s it. Now, you can normally call ExportedFunc from .net without any problems. You must remember to do the same for the begin/end runtime, call them first from .net, and you’re done. The gates to Haskell paradise just pop’ed in your Visual Studio world.

Conclusion

So good luck combining the best of both worlds. I don’t know if the DLL problem with GHC (version 6.10.4) will be fixed soon or not, but in the mean time you can still use this workaround.

There is an interesting follow-up in the stackoverflow question explaining how to avoid all my problems in a much nicer way. To bad I didn’ find it myself…