DllExport as opposed to DllImport in C# | Tech Off

BitFlipper

I am working on a C# 3.5 plugin that is used by an unmanaged C++ host application. This C++ application is a 3rd party commercial application and I don't have the source code to it.

Anyway, I have the plugin working using a managed C++ helper DLL that handles all of the unmanaged to managed API calls. My plugin has a managed UI that is embedded into a native window that is supplied by the unmanaged application. I use NativeWindow to do this.

But now I have run into a problem where I can't get Drag & Drop to work. This has something to do with COM not being initialized or something, and I am looking at ways to solve this.

Anyway, that is not the main reason I'm here. I heard rumors that there could be an easier way to do something like this in C# 4.0. Is this true? Ideally, it would be something like:

[DllExport]

private static void MyMethod(...)

{

...

}

So what happens is that the method is exported so that it becomes visible as a C entry point using the same marshalling features that DllImport gives you. This way I can write my plugin as a single C# DLL that exposes C entry points. Hopefully it will also do proper COM initialization etc.

Does anyone know if something like this is forthcoming in C# 4.0?

BitFlipper

It doesn't look like anybody really cares about this scenario, but in case someone does, I did some reasearch and found the following:

So it turns out that this is possible, except that this functionality is not exposed all the way through to C#. The IL supports this scenario, so to make this work, you need to do the following:

Disassemble your C# DLL to an IL text file.
Parse the text file and modify it to add the required entries that will export the methods you tagged with your custom DllExport attribute.
Assemble the IL text file back into a DLL.

This can all be automated via a custom utility and and some post-build steps. I found the following sites, after which I wrote my own utility to do all the above. It works quite well. You can even debug the C# DLL just like any other C# DLL (if you add the /pdb switch to the assembler, which isn't mentioned in either of the below links). The only problem is that Edit-And-Continue doesn't work because the assembly has been modified after it has been compiled.

http://www.codeproject.com/KB/dotnet/DllExport.aspx

http://www.codeproject.com/KB/dotnet/DllExporter.aspx

So I wonder why MS didn't connect all the dots and allow us to mark methods with a DllExport attribute. It would make some people's lives so much easier.

figuerres
???

In reply to BitFlipper

#Oct 11th @ 9:54 AM

making the dll visible to COM will not work for you? that is the normal way to let unmanaged code call into a managed dll.

and com-vivible is very simple to do in .net and vs.

BitFlipper

In reply to figuerres

#Oct 11th @ 3:17 PM

Unfortunately the plugin I'm writing needs to use an industry standard C API that does not use COM. There are thousands of plugins, both free and commercial, using this API so there is nothing I can do to get them to use COM. See this for more details on the API.

Unless I am misunderstanding something, I am stuck using the C API that is published to work with these DAW hosts.

figuerres
???

In reply to BitFlipper

#Oct 11th @ 11:06 PM

Ah...

perhaps a spot for you to write and then license a plugin for .net for this?

you write a C++ /CLR aware plugin that becomes a wrapper for other plugins to connect with...

a "bridge" between the two so to speak.

BitFlipper

In reply to figuerres

#Oct 12th @ 5:13 AM

I have been using a C++/CLR wrapper but now I have found a way to completely do away with this intermediate DLL. These VST plugins tend to be single-DLL plugins, so to have had the requirement for the intermediate DLL was somewhat of a pain. I much prefer doing everything in C#, since the managed C++ code just isn't as nice to work with.

Since VST plugins do realtime DSP, C# isn't the first choice for these kinds of plugins. I found that C# is fast enough to do everything I need but a lot of other people won't feel the same way. Audio projects often have dozens of plugins, and CPU usage gets to be a real issue in these situations, where the smaller you can make buffers, the better, resulting in less latency from the time that audio enters the computer until it is played back through the speakers. But smaller buffers means there will be more calls made during the same timeframe, resulting in more CPU overhead. It is an ongoing battle between lower latency and CPU usage.

Anyway, I don't expect to sell my software, but who knows, maybe in the future. Soon .Net 4.0 will allow multiple CLR versions to be loaded at the same time, which might help C# becoming viable in these situations.