Instantiate Unmanaged Class From .NET

I'm finding plenty of examples through Google of how to call an API function within an unmanaged DLL from .NET code, but what about instantiating an object from that unmanaged code?

I'm currently tinkering with an old legacy application at work (and开发者_C百科 I'm yet unconvinced that we're going to be able to do anything with this, but tinker and research I must) that the company wants to migrate to .NET. It appears that this was attempted before, and I'm looking through that now. The most common compile errors are references to old DLLs that the project doesn't understand.

An example of a line of code in this would be:

Dim cAccounts As HSVMETADATALib.HsvAccounts

There's a broken reference to the library in the project, which I believe is the result of some wizard-driven attempt to just port some pre-.NET project to .NET. I have the DLL that it's looking for, but adding a reference to it returns the error:

A reference to 'HFMConstants.dll' could nto be added. Please make sure that the file is accessible, and that it is a valid assembly or COM component.

Now, I know nothing about this DLL. And I have very little experience in pre-.NET Windows programming. So I've been looking around online for information about using an old DLL in this code, and it all focuses on calling API functions within the DLL. Looking through this code, however, it's much less about API functions and more about objects. So how would I go about instantiating an instance of one of these objects?

(Be aware that this is one of those situations where we don't even know if we have the right source code, there's no documentation, nothing about the ownership and maintenance of this application was built to last. But this one hurdle of being able to instantiate objects from the external DLLs, which are from some unknown and potentially unreachable at this point third party source, will cut down on most of the compiler errors and help us get into a little more meat of the code, possibly even getting a stripped-down version at least compilable.)

It's vague, but it's worth asking :)

I suggest you try opening the DLL with Dependency Walker. This should give you more information about the DLL's internals and API.

See Also:

Referencing a non-CLR DLL
http://illuminatedcomputing.com/blog/?p=44

You will need to try to find out more information about this DLL. For example if it is a COM object you could generate a strongly typed managed wrapper that will allow you to consume it using tlbimp.exe. If it is a standard Win32 library you will need to find out whether it exposes some functions, what are their names and arguments in order to PInvoke them. You could use dumpbin.exe to see a list of exported function names.

You could comment out all the code that doesn't compile, anything dependent on files you don't have.

If you have the .dll and all it's dependent .dlls, you should be able to add it to your project references. If not, without external documentation, it's pretty hard to figure out what that compiled code was doing.