Force .NET interop to use local COM DLL

Question

Is it possible to force an interop assembly to reference a local copy of its associated COM DLL?

Here's the scenario:

I have a .NET app that references an interop assembly (Interop.OTAClient.dll), which is the interop for a COM DLL (OTAClient.dll, which is the automation API for HP Quality Center). I'm not very knowledgable on COM, but as I understand it the interop assembly looks up the COM classes via GUID references in the registry, rather than pointing to a specific file.

The issue I have is that the copy of OTAClient.dll that the registry keys point to gets overwritten by different versions depending on which version of QC I've just logged into in a browser, and the different versions of these DLLs are not compatible with each other. The .NET app will only be connecting to a specific version of QC, so I cannot have the COM DLL varying in this way.

Any suggestions would be greatly appreciated, as this behaviour is really irritating. I've seen other questions on COM interop issues, but they all seem to be about forcing a local version of the interop DLL to be used instead of one in the GAC, rather than this particular scenario involving the actual COM DLL.

Kiloton

Answer 1

You want Registration-free COM.

Pace

Hi Pavel. Thanks for the link - I followed the example, and VS generated the manifest entry for OTAClient as expected. However, I still see the same symptoms if the newer version of the DLL has been used last by the browser app that also uses that DLL. Do you think it's possible that OTAClient has its own dependencies that are also getting overwritten with newer versions? If so, any suggestions on how I might deal with that? – Kiloton

It may be possible if those dependencies are themselves COM components. If so, you should handle them in a similar way (so that you end up with a self-sufficient set of libraries). – Pace

Answer 2

Pavel pointed me in the right direction, so I will be marking his as the answer. For the benefit of everyone else, here's what I did:

1. Added a reference to the original OTAClient.dll and let Visual Studio generate the interop library.
2. Right-click on the referenced library in Solution Explorer and click Properties. Then set Isolated to True. This causes VS to generate a manifest file telling your program to look locally for your COM library instead of at the one listed in the registry.
3. Specific to my scenario - I also had to reference WebClient.dll from Quality Center and set Isolated to True for that also. This is not used directly by apps using the OTA API, but seems to be referenced by OTAClient.dll.

This way, you can be logging in and out of QC instances whose versions differ from the one used by your app without breaking it. In my case, I have a local QC instance that is v9 and used for project-specific automation (for various reasons, it's heavily customised to meet our needs, has lots of space for screenshot storage etc), and to which my application connects. However, for manual testing I also need to login using in IE to a v9.2 instance located elsewhere. If I had previously logged into the v9.2 instance, I would then have to open the v9 instance in IE and let it redownload the controls before running my app again... and now I don't. :)

Kiloton

Answer 3

A small example showing how Web.config changes after we set Isolated property to true, would help others in understanding what is actually happening at back when we set Isolated property to true. VS actually enters few lines in your code, so that it will use com Dll of specific CLSID.

Actually I do have two .Net applications on the same server, where one application uses Quality center 10.0 Dll and Other is upgraded to quality center ALM 11.0. So on the same server we can not register a DLL with same name.

Pediform