Question

I have a C# 4.0 application that is referencing a type library from a C++ application. This is used for some secure COM interop, a question I originally had asked here.

On my development machine this second application is installed so I can compile without any issues. If I attempt to compile on our automated build server, or any machine with Visual Studio installed but without this second program, I receive the following errors and compilation fails:

Text for google:

The type or namespace name could not be found (are you missing a using directive or an assembly reference?)

Cannot get the file path for type library “guid….” version 1.0. Library not registered. (Exception from HRESULT: 0x8002801D (TYPE_E_LIBNOTREGISTERED))

The referenced component ‘SecurityAgentLib’ could not be found

Picture for readability:

I’m not sure how to get around this other than by installing the application that registers the actual dll that implements these types, but I don’t want to do that on our build server. The code that uses these types are wrapped in a class that is never instantiated unless prerequisite checks are run to verify the app is actually installed, so there is no chance of a runtime error. In fact I can run my app just fine on a machine without the second app installed – I just can’t compile it there.

In visual studio the reference points to the .tlb file which is included in the solution directory, so the tlb file itself is present.

I can’t imagine it should work this way, and I’ve searched around, but I’m apparently not searching for the right terms.

EDIT:
Running tlbimp.exe generates a dll but the type library should be sufficient for compilation, I thought at least. There is also an issue of broken references. I was reading this article Troubleshooting Broken References and it says that if the reference was to a COM component that is not installed than installing the component corrects the error, which is true.

Installing it on the build server really isn’t an option. Opening visual studio and re-adding a reference if the path was broken doesn’t work either.

I was able to use tlbimp to create a dll and used visual studio add a reference to that dll. That let me compile, but how would this work in an unattended build server?

EDIT
Okay I came up with two solutions that worked given my requirement of this all being unattended

1. Ran tlbimp to create a dll from the type library. I removed the reference to the tlb from my project and added a reference to the dll itself. When the source code was copied over to a new computer it compiled without issues.

In this scenario ideally we would checkout from SVN on the build server and copy the latest DLL from the second project, then compile this project.

2. I also removed the tlb and added the dll in visual studio and did a diff on the .csproj file. I don’t see any downside to just having a reference to the dll instead of the tlb but if needed the build server could make modifications directly to this file to remove the tlb section and add a reference to the dll following a build of the second product.

Answer 1

Here are a couple options that each worked.

• Ran tlbimp to create a dll from the type library. I removed the reference to the tlb from my project and added a reference to the dll itself. When the source code was copied over to a new computer it compiled without issues.

In this scenario ideally we would checkout from SVN on the build server and copy the latest DLL from the second project, then compile this project.

• I also removed the tlb and added the dll and did a diff on the .csproj file. I don’t see any downside to just having a reference to the dll instead of the tlb but the build server could make modifications directly to this file to remove the tlb