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 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