Exposing DLL classes to .NET?

[Nerseus]

Howdy!

 

I'm trying to write a DLL that will interface into an existing library (more or less a plugin). The executable loads a DLL file (say "test.dll") and expects that DLL to implement a specific class. The class definition is in a C++ header file (.h) that I have.

 

I can easily create a test project in C++ that implements the given class and it works. Meaning, my standard C++ DLL compiles and the external executable loads it and instantiates the class and calls the method I need, doing what I want (yee haw!).

 

Now there are a LOT more classes and a lot more code to do and I'd really prefer to NOT do it all in C++ as I'm not that proficient. And I hate doing it all in VS6 (I can't use C++ .NET as the class I need to implement contains some functions with optional parameters and other issues that .NET doesn't like right now).

 

My idea is to create a simple C++ DLL in VC++ 6 (or maybe C++ .NET) that can then instantiate a C# DLL and passthrough all method calls.

 

Since I have the LIB file (and mabye even the source that created the LIB file), I was hoping there's a way to extract out the definition of the classes and get them in C# syntax. Asking too much? I've only just begun! But that's all for now :)

 

This is all to use an existing library from a 3rd party that no longer supports the product. We know the code works because we've used it, but we'd really like to port as much as possible to C# without taking the hit of converting the WHOLE C++ project to C#.

 

-nerseus

[Nerseus]

Break down the previous into two simpler questions:

1. Suppose I wrote a managed C++ DLL that contained a class that was inherited from a class defined in an .h file. How would I go about passing that class (from C++) to a C# DLL?

2. Or, how would I expose the C++ class to the C# DLL?

 

If it's a managed C++ DLL, is it much like a C# DLL in that I can just add a reference in the C# project and get access to the class?

 

Would it matter if the C++ DLL (written in VC++ .NET - whatever version it is, 7?) were unmanaged? Could I still add that DLL reference to a C# project, or would it have to be called using DllImport. If I have to use DLLImport, would I have to define the class in C# in order for the DllImport definition to match the class being passed in from the C++ DLL?

 

Egads I'm tired and working too much, too late.

 

If you can help, thanks. If not, join the crowd around my desk in the morning for Krispee Kremes :)

 

-Nerseus

[AndreRyan]

I think only Managed classes can be used by Managed applications so you might need a Managed Class to wrap the Unmanaged one or a C++.Net Managed Class that accesses the Unmanaged methods in Unmanaged classes. This is just a suggestion, someone probably has a more useful answer.

[Derek Stone]

There are two types of DLLs one can interoperate with from managed code: standard libraries and COM libraries.

 

Standard libraries expose methods and methods only, meaning they have no concept of classes, nothing but a figment of our imagination back in the days of C. You'd use platform invoke (of which DllImport is a part of) to call these methods.

 

COM libraries on the other hand support full OOP and contain the classes we now all know and love. To interop with these libraries from .NET we create a COM-callable Wrapper (CCW).

 

Now the question is this: what is this legacy code you're talking about? Is it a static library (*.lib) or is it in an executable format (*.dll)? If it's the former your best bet would be to generate a COM wrapper which exposes the necessary method interfaces and types to the outside (non-C++) world. If it's the latter you'll need to determine if the DLL is standard or if it is exposed via COM, and then make any decisions based off of that.

 

There's a good chance you've answered these already, and I'm just blind, but bear with me.

[Derek Stone]

I think only Managed classes can be used by Managed applications

Very true, but what defines a managed application?

[Nerseus]

I'm still investigating what I've got :)

 

It appears that the library I'm dealing with is made to run from an EXE. The EXE launches a specifically named DLL (standard, non-COM) and is expecting it to implement a specific class (?) or at least a specific function.

 

The DLLMain function does nothing (returns 1), so it's not invoking anything through there. I'm not that familiar with unmanaged C++ (systems programming in college was probably the last real work I did), but it appears that the EXE must have been compiled with knowledge of this class (an interface actually), and it expects my DLL to implement it. Now how it knows which class (in case my DLL were to expose two?), I have no idea. I'm still playing around.

 

I've been able to get the sample code to work and I can create my own from scratch. I'm petrified of trying to have my unmanaged C++ class call into a COM component (wrapping in the backwards sense). I'm not sure how else I'd get the unmanaged DLL to invoke or instantiate my C# DLL.

 

It might be as simple (assuming I even knew how to instantiate a COM component in C++ to begin with - something about CoCreateInstance blah blah) as creating one global instance of my C# class (exposed as a COM object) and having my COM interface mostly match what the C++ class has. That way every call to my unmanaged DLL could call a similar method in the COM class. I'm not sure of all the types of parameters I'll be dealing with yet and that may throw in even more kinks (passing structure and class pointers through to a managed C# application wrapped by COM - egads).

 

-nerseus

[Derek Stone]

I think I understand what your attempting to do now.

 

Executable --> Unmanaged C++ library --> Managed C# library

 

You've got two choices as far as I see it:

 

1) As you mentioned, instantiate a .NET DLL that's been exposed through COM

 

2) Load the CLR into the unmanaged C++ library and invoke managed methods through the provided interface

 

Both are ugly as far as I'm concerned, but it's either ugly or code everything in C++.

[Nerseus]

A small update. I did manage to get the DLL created using .NET (non-managed) and it worked like a charm. I then created a C# class library and exposed it as a COM object (set of objects really) and created and used that COM object from C++. It's not pretty, but it works. And now that the foundation is done, I can do all the "real" work in C#. Performance hasn't been an issue yet, even with the extra layers (going to a second DLL AND a COM wrapper for my .NET objects).

 

And I learned far too much (and yet so little) about COM in C++. Ugh. Something I'll have forgotten by New Years.

 

-Nerseus