Wrapping Unmanaged Library - Options.

Hello,

I'm trying to reuse an existing C++ audio synthesis library (STK), from a WPF application written in C#, with a GUI designed in Sparkle. The way I did this was to recompile STK as a CLR library, with wrapper ref classes for each class that was accessed by the C# front end.
All other build settings were identical to the native dll build of STK.

The GUI-to-STK-wrapper-classes interface is not very chatty.

However, going by the clicky audio, there seemed to be a *huge* performance hit. Is this because compiling STK as a CLR library defaults to generating MSIL for the entire library Even so, is that a problem If it is, I only want MSIL for the ref classes that are exposed to C#, and retain the rest as native code, so that C#-to-ref-class calls are managed, and ref-class-to-unmanaged-class calls are through IJW.

It seems that one way to do this would be to add a '#pragma unmanaged' directive to every file in the library and then build a clr assembly that includes the ref class wrappers. That seems somewhat tedious. Is there a better way to do that Or is there an alternative to reuse an unmanaged dll build of STK from the C# front end

Thanks in advance,
-Vamshi

Answer this question

Wrapping Unmanaged Library - Options.

TjMulder
There are a number of possibilites. It really depends on how much of your code was compiled into MSIL and how much was compiled to native. If there was a lot chat between the two, there could have been a lot of thunking slowing you down. Maybe someone more familiar with the code generation for /CLR could comment
DarkBagler
I managed to get the whole configuration working. The performance is back to that of the original C++ library. And I get all the WPF funtionality and can continue to program the front end in C# and design it in Sparkle. This is great!

Thanks again!
-Vamshi
Ron1966
Indeed. Not sure why I didn't think of that :).
Thanks again!
-Vamshi
Peter Barnum
Can you simply compile your wrappers /CLR and have them call the natively compiled STK
redsmurph
Incidentally, is the huge performance hit explained by the fact that I compiled the entire library as a managed assembly Shouldn't most of the classes be marked unmanaged anyway Was I doing something wrong I combed through the build settings, the Win32 build and the CLR build were identical. I think I had to add a entry for a P/Invoke-ation of a GetForegroundWindow call that STK was making somewhere. Other than that, it was identical.

Thanks,
-Vamshi
Wrapping Unmanaged Library - Options.

Answer this question