Managed program accessing classes and dialogs in unmanaged DLL

  • Thread starter Thread starter Dave
  • Start date Start date
D

Dave

I've seen at least one article on this: How to access classes, etc.
managed-to-unmanaged. I can't find it. Any tricks or pointers?
I guess the class name won't get munged but I'm not clear about
necessary class declarations.
 
Dave said:
I've seen at least one article on this: How to access classes, etc.
managed-to-unmanaged. I can't find it. Any tricks or pointers?
I guess the class name won't get munged but I'm not clear about
necessary class declarations.
Click to expand...

There are a few ways to go.

..Net provides a "platform invoke" service for calling functions in DLLs that
export a simple procedural entry points. Basically, you define an external
function and tag it with the DllImport attribute. An example is here:

http://msdn.microsoft.com/library/d.../cpguide/html/cpconplatforminvokeexamples.asp

Of all the CLS compliant languages of MS, only Managed C++ ( v1.1) and
C++/CLI (v2.0) allow mixing of managed and unmanaged code in the same
module. The compiler generates the thunks to hop the boundary between
environments.

This describes the situation under .Net 2.0

http://msdn.microsoft.com/msdnmag/issues/04/05/VisualC2005/

and this

http://msdn.microsoft.com/library/d.../vcmxspec/html/vcmg_part2Start.asp?frame=true

under 1.1

At that link you'll also find mention of the third method in which .Net
clients consume services written to the COM specification as if they were
..Net classes.

Regards,
Will
 
There are a few ways to go.

.Net provides a "platform invoke" service for calling functions in DLLs that
export a simple procedural entry points. Basically, you define an external
function and tag it with the DllImport attribute.
Click to expand...

Thanks as always, Will. I've used PInvoke on straight non-class-based
DLLs so I'm clear on that, but I was wondering how a class object
inside that DLL would be...:

1: Accessed (function-wise) via PInvoke.

2: Declared so names of functions inside a class don't get munged.
(I suspect this just requires the normal "C" prefixes).

In the past I've used managed extensions to wrap a straight DLL into a
'local' unmanaged class, then wrapped that class with a managed code.
I'm thinking that C++/CLI will eliminate the clutter and maybe afford
some speed.

But for new projects it would make sense to regenerate the primary
DLLs with some class structure to begin with, hopefully eliminating a
layer of adapter code. I'm not sure how you'd access that unmanaged
class DLL from managed code though.

Ex: How to bring in an MFC dialog that was originally written w VS6?
I think I've seen this somewhere, but can't find it.
 
Dave said:
Thanks as always, Will.
Click to expand...

You are welcome.
I've used PInvoke on straight non-class-based
DLLs so I'm clear on that, but I was wondering how a class object
inside that DLL would be...:

1: Accessed (function-wise) via PInvoke.
Click to expand...

Straight to the crux of the issue. :-) With IJW, you don't need to use
P/Invoke.

What I did was to create a .Net proxy class with one public method for every
method of the native class.

The constructor of my managed class uses IJW to call a native function which
creates an object of the native class. That native function just invokes the
constructor straight-away. I save a pointer to that native object as a
private member of .Net class.

Every public method of the .Net class uses IJW to call a native stub to
marshall arguments and to call the corresponding native method of the object
using the saved pointer. After the call to the native method returns, any
result is unmarshalled back to managed code.

In my case I was adapting some stuff of mine to accomodate the .Net
platform. And since I developed both the native and managed sides of this
application, I didn't need to worry about the name mangling issues that
arise when you try to export a class based interface across a DLL boundary.

If that's a concern for you, then you'd be better off with flattening the
exported interface or using COM.

Regards,
Will
 
Back
Top