Registering COM referenced DLLs on a build server

Question

We're developing a C# application that references a few COM libraries (AutoIT for example).

I am including all referenced components under source control, in a 3rd party "Libs" folder.

The problem is that COM dll's don't have a HintPath property in the .csproj file, and i assume these must be manually registered using regsvr32 (or using a script of some sort).

I am currently looking into creating an MSBuild script that will run before every build, however i couldn't figure out if i should be manually calling regsvr32.exe or use some predefined MSBuild task?

Currently, this is what i've attmpted as a test:

 <?xml version="1.0" encoding="utf-8"?>
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003" DefaultTargets="Build">
  <ItemGroup>
    <MyAssemblies Include="D:\*.dll" />
  </ItemGroup>
  <Target Name="Build">
    <RegisterAssembly
      Assemblies="@(MyAssemblies)" >
    </RegisterAssembly>
  </Target>
</Project>

This generates errors that the DLLs i've placed in the given folder are not valid DLLs.

What is a good solution for this problem?

EDIT:

Projects that reference COM dlls have something similar to this in the .csproj file:

<COMReference Include="AutoItX3Lib">
      <Guid>{F8937E53-D444-4E71-9275-35B64210CC3B}</Guid>
      <VersionMajor>1</VersionMajor>
      <VersionMinor>0</VersionMinor>
      <Lcid>0</Lcid>
      <WrapperTool>tlbimp</WrapperTool>
      <Isolated>False</Isolated>
    </COMReference>

This does not include any hint path as other managed assemblies, so on a build server, the referenced COM dll is not found.

When registering the COM dll on the build server using REGSVR32, the build succeeds.

Answer 1

You don't register COM servers on a build server. That's only required when you actually want to run the compiled code. What you need is the type libraries for the COM servers so you can get the interop assemblies. Which you create with Tlbimp.exe.

Whether you want to run Tlbimp on the build server or up front on a dev machine depends a great deal on how you deploy these COM servers. Keeping a copy of the COM executables and .tlb files very close to your interop libraries is a good idea. In other words, check them in. The installer can now retrieve a known-good version of the COM server as well.

Answer 2

For my original answer to a similar question see: TFS Build server and COM references - does this work?

A better option for build servers may be to use the COMFileReference item in your project file instead of COMReference. An example would look like this:

<ItemGroup>
   <COMFileReference Include="MyComLibrary.dll">
     <EmbedInteropTypes>True</EmbedInteropTypes>
   </COMFileReference>
</ItemGroup>

The COM dll doesn't need to be registered on the machine for this to work.

Each COMFileReference item can also have a WrapperTool attribute but the default seems to work fine. The EmbedInteropTypes attribute is not documented as being applicable to COMFileReference, but it seems to work as intended.

See https://docs.microsoft.com/en-ca/visualstudio/msbuild/common-msbuild-project-items#comfilereference for a little more detail. This MSBuild item has been available since .NET 3.5.

Answer 3

1) Try to reference the COM libraries to your csproj as references - if you haven't done so.

2) Try to append to your csproj file:

<Project ... >
    ...
    <Target Name="BeforeBuild">
        <Exec Command="regsvr32.exe yourComponent.dll" />
    </Target>
</Project>

PS: if you are using some sort of build server software you should not modify the csproj but the script used by the build at the server.

Answer 4

I'm not sure, if there's any task in MSBuild, to call regsvr32, but REgisterAssembly is calling regasm.exe - that is - registering .NET components for COM interop.

I am sure, that just calling regsvr32 manually would be the fastest way to achieve the desired result.

Another thing is - what will happen if the COM DLLs are already registered by the previous build and you'll run your build script again? (I don't really know how the regsvr32 will react, just a thought here)