it works, but I wonder when or how the GC kicks in, more research to do ....

I needed this exact same functionality when I wrote some managed VST plugins. VST plugins are audio plugins for audio applications that uses a purely C interface. In my project, I created a DllExport attribute, and a post-build step would decompile to IL, then parses and sets the correct flags and does some other "things", and then recompiles the IL. At that point those methods marked with DllExport shows up as C entry points. This works quite well, and the unmanaged audio applications can see and call into the managed DLL as if it was purely C/C++ code. The .Net runtime is fired up automatically as part of any initial C call into the DLL.

See this thread that contains a more detailed explanation and code for an early version of my parser. I feel it is a hack, and wish MS would just plumb this stuff all the way though, as it's 98% all there already.

If this was not what you were referring to, just ignore my post...

57 minutes ago, BitFlipper wrote

I'm not familiar with Redhawk but I assume you mean "Reverse P/Invoke"? If so, yes the .Net framework supports being called from C. Unfortunately this functionality is not plumbed all the way through to say, C#. Ideally there should be a "DllExport" attribute that allows a .Net assembly to have that method exported and be able to be called purely from C (while initializing the .Net framework during the 1st C call).

Just expose it as COM and be done with it

1 hour ago, BitFlipper wrote

I'm not familiar with Redhawk but I assume you mean "Reverse P/Invoke"? If so, yes the .Net framework supports being called from C. Unfortunately this functionality is not plumbed all the way through to say, C#. Ideally there should be a "DllExport" attribute that allows a .Net assembly to have that method exported and be able to be called purely from C (while initializing the .Net framework during the 1st C call).

I needed this exact same functionality when I wrote some managed VST plugins. VST plugins are audio plugins for audio applications that uses a purely C interface. In my project, I created a DllExport attribute, and a post-build step would decompile to IL, then parses and sets the correct flags and does some other "things", and then recompiles the IL. At that point those methods marked with DllExport shows up as C entry points. This works quite well, and the unmanaged audio applications can see and call into the managed DLL as if it was purely C/C++ code. The .Net runtime is fired up automatically as part of any initial C call into the DLL.

See this thread that contains a more detailed explanation and code for an early version of my parser. I feel it is a hack, and wish MS would just plumb this stuff all the way though, as it's 98% all there already.

If this was not what you were referring to, just ignore my post...

Also, the typical VST convention is to use a single DLL for the plugin, with no installer etc. This is because of the way VSTs are managed by audio applications, etc. When using the managed C++ approach, you end up with at least 2 DLLs. Functional but not ideal. My solution creates a single DLL solution (actually one for 32-bit and one for 64-bit during the post-compile step) that anyone can just copy into their VST folder, then let the audio application scan the VST folder, and it would find it thinking it uses the C VST API.

COM can't possibly enter into this picture. Why do people (and MS in general) still think COM can solve all these types of interop problems?

@contextfree`: Maybe, but it is a cross-platform and very well established C API so there isn't even a chance they will ever make future versions use COM. MS had the "DirectX" COM-based plugin format many years ago, and there was a time when many Windows audio applications supported it. But VST is now the established API with almost no support for DirectX from plugin creators these days.

5 hours ago, BitFlipper wrote

I'm not familiar with Redhawk but I assume you mean "Reverse P/Invoke"? If so, yes the .Net framework supports being called from C. Unfortunately this functionality is not plumbed all the way through to say, C#. Ideally there should be a "DllExport" attribute that allows a .Net assembly to have that method exported and be able to be called purely from C (while initializing the .Net framework during the 1st C call).

This is a primer to the fabled 'Redhawk'  ... its the future api of windows (or rather the base classes of windows)

http://channel9.msdn.com/Forums/Coffeehouse/System-Language-Runtime-or-Project-Redhawk-surfaces-in-Windows-8

This is awesome stuff ... simply awesome!!!

No, AFAICS, in Redhawk the whole framework is exposed as this way, and this is THE native way of calling methods, even if you are using C#.

Sure you have better language support as C# so you can do it more natually and properly, and with metadata in development time, but in the end you are calling other methods/assemblies as this, and your referenced assemblies are properly linked as implicitly imported DLLs, int the imports table, so Dependency Walker can see it. Also, all of the public methods in your assembly are exported as C functions as this.

But these function are not 'supposed' to be Reverse P/Invoke exports, they are actually Redhawk 'native' stuff, designed to be called from C#, so it suprised me that they are actually using native calling conventions and can actually be called from C++ and 'kinda' works.

Talking about Reverse P/Invoke, as Redhawk is supposed to unify the native and managed world, or at least much better interop, so yes, I can see there are also natual ways to do it in Redhawk.

One of the 2 user of Redawk in Win8 is whealogr.dll, and it is doing just that, and its exactly your scenario, as whealogr need to comply with the WDI 'plugin' interface, with is defined as C funtions like "WdiDiagnosticModuleMain/WdiGetDiagnosticModuleInterfaceVersion/WdiHandleInstance", so whealogr exports these 3 C functions, and internally they are just C# static methods in a class, exported directly, they have a call to 'RhpReversePInvoke()' in the begining, and a call to 'RhpReversePInvokeReturn' in the end, so these are 'really' Reverse P/Invoke functions, it wont suprise me that I can call those in C++.

plus: I noticed that there is an Attribute called System.Runtime.InteropServices.NativeCallableAttribute which MIGHT be related.

And, the other user of Redhawk is 'PowerWmiProvider.dll', and it exposes a COM interface, so I can see the team is using these 2 dlls to test the 2 main interop scenarios between Redhawk world and other parts of Windows.