CODEWITHSUNDEEP
c#commsbuild
Netfangled
Netfangled

Reputation: 2081

Resolve COM Reference programmatically

I'm trying to list all the references of an msbuild project and their location on disk.

So far I can get the project references and assembly references just fine, but I'm having trouble with the COM references. This is what most of the references look like in the project files:

<COMReference Include="[name of assembly]">
  <Guid>{GUID-GOES-HERE}</Guid>
  <VersionMajor>1</VersionMajor>
  <VersionMinor>0</VersionMinor>
  <Lcid>0</Lcid>
  <WrapperTool>primary</WrapperTool>
  <Isolated>False</Isolated>
  <EmbedInteropTypes>True</EmbedInteropTypes>
</COMReference>

I have absolutely no clue how to get the path to the COM DLL. A bit of googling told me that I could look at HKEY_CLASSES_ROOT\CLSID\{GUID-FOUND-IN-PROJECT-FILE}\InprocServer32 and grab the key's default value. When I look in the registry using regedit, it seems to be right, but every time I do this through C#, the registry key is always null. I've also looked under the Wow6432Node\CLSID with the same result.

Googling further turned up the msbuild ResolveComReference task and how I could use the Microsoft.Build namespace to programmatically use msbuild (ResolveComReference class), but I've only found how to use this namespace to build a whole project, instead of executing a single task.

How do I get the location of a COM DLL using the information in a project file?

EDIT

The reason for doing this is to automate our build process. On one hand, this would let us include our COM DLLs in our installers (using WiX's Heat tool, or John Robbin's Paraffin tool). On the other hand, it would work around an issue we have with msbuild. We let msbuild resolve all dependencies. If Project1 and Project2 both reference the same COM DLL and Project1 references Project2, it crashes because it tried to add the COM DLL twice.

Upvotes: 2

Views: 1925

Answers (1)

Hans Passant
Hans Passant

Reputation: 941407

The reason for doing this is to automate our build process

That no doubt is part of the problem. A <COMReference> is convenient only when the COM server is installed on the machine that performs the build. That gets to be a problem if you want to reproduce the build on another machine. The odds that the right COM server isn't installed on that machine increase considerably. It certainly would explain why you cannot find it back in the registry.

To make the build reproducible on any machine, it gets to be important to break the build dependency. You do so by running Tlbimp.exe to create the import library. And check it into source control. And add a regular assembly reference to the generated DLL so you just have a simple file dependency.

The disadvantage is that you'll freeze the dependency and will get into trouble when the COM server is evolving. Boilerplate is that the {guid} changes when the version of the server changes, required to avoid DLL Hell. If that's the case then you'll need a procedure that ensures that COM server updates are registered on all machines that perform a build. It is not that much of a problem in practice because having a COM dependency always means that you also have a deployment dependency. You also need to make sure the server is available on the user's machine. That's always a big deal and you almost never frivolously change versions.

Upvotes: 6

Related Questions