I'm forced to use a third-party COM component in an application, and I'm having issues adding the reference to my project.
I've added this DLL as a reference to a project before, but in the past it would link directly to the DLL, such that the "Path" in the reference's properties would be filesystem path where the DLL was installed (i.e. not relative to my solution's directory). However, now, when I add the reference, the "Path" is to my project's obj directory, "Embed Interop Types" is set to True, and it's listed as an ActiveX component (which is not correct).
Then, I stumbled upon this MSDN article, which says:
If you want to add a reference to a registered COM DLL that contains an internal manifest, unregister the DLL first. Otherwise, Visual Studio adds the assembly reference as an ActiveX Control instead of as a native DLL.
Well, there you have it. That's my exact problem. I need the native DLL, but I'm getting an ActiveX Control instead. So, I did as it suggested and unregistered the DLL. However, when I then try to add the reference, I get an error saying:
A reference to ... could not be added. Please make sure that the file is accessible, and that it is a valid assembly or COM component.
If I register the DLL again, I'm able to add it as a reference, but again, it's added as an ActiveX control. At this point, I don't know what else to do. Microsoft is very clear that I must unregister it before adding it as a reference, but then Visual Studio 2013 apparently won't let me add an unregistered DLL. Any one have any idea how to work around this?
UPDATE
So, apparently a recent update to this app made COM the only option (no directly using the DLL). The fact that it was added as ActiveX didn't mean anything. The problem turned out to be that this was a 32-bit library trying to run in 64-bits. I knew that was a potential problem, but switching the platform target to x86, still resulted in an error so I ended up chasing a red herring. Turns out IIS Express 8 runs natively as 64-bits even if the platform target of the site you're debugging is 32-bit. I had to go into Visual Studio options and uncheck the flag that tells IIS Express to run 64-bit (under "Web Projects") and then everything ran fine.
So, since adding the registered DLL was pretty much a no-go, I focused instead on trying to figure out why Visual Studio wouldn't let me add it when it was unregistered. I mean, sure, I might get an error about it being an unregistered DLL once I tried to run the project, but it should at least let me add it as a reference, regardless.
I eventually stumbled upon tlbimp.exe, which according to Microsoft:
The Type Library Importer converts the type definitions found within a COM type library into equivalent definitions in a common language runtime assembly. The output of Tlbimp.exe is a binary file (an assembly) that contains runtime metadata for the types defined within the original type library.
Okay. Well anyways, I opened a Visual Studio Developer Prompt (regular cmd doesn't have tlbimp.exe on the path), and ran my DLL through it. It created a new DLL, which I was able to add as a reference, and it satisfied my project dependencies. However, I haven't tested it just yet to make sure everything still works as it should once this thing is running, so I'll update with what I find there.
UPDATE
Yeah, so this doesn't work either. I get the same error once it's running saying that the class is not registered. Only now, I can't register this DLL because tlbimp.exe removes the entry-point.