title: Unable to compile .NET application with referenced TLB when library is not registered
body: <p>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 <a href="https://stackoverflow.com/questions/8000123/integrating-c-sharp-c-application-using-secured-com-via-referenced-c-tlb">here</a>.</p>
  
  <p>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:</p>
  
  <p>Text for google:</p>
  
  <p>The type or namespace name could not be found (are you missing a using directive or an assembly reference?)</p>
  
  <p>Cannot get the file path for type library "guid...." version 1.0. Library not registered. (Exception from HRESULT: 0x8002801D (TYPE_E_LIBNOTREGISTERED))</p>
  
  <p>The referenced component 'SecurityAgentLib' could not be found</p>
  
  <p>Picture for readability:
  <img src="https://i.stack.imgur.com/cbipK.png" alt="compilation error"></p>
  
  <p>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.</p>
  
  <p>In visual studio the reference points to the .tlb file which is included in the solution directory, so the tlb file itself is present. </p>
  
  <p>I can't imagine it should work this way, and I've searched around, but I'm apparently not searching for the right terms. </p>
  
  <p><strong>EDIT:</strong>
  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 <a href="http://msdn.microsoft.com/en-us/library/ayds71se%28v=VS.100%29.aspx" rel="nofollow noreferrer">Troubleshooting Broken References</a> 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.</p>
  
  <p>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. </p>
  
  <p>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?</p>
  
  <p><strong>EDIT</strong>
  Okay I came up with two solutions that worked given my requirement of this all being unattended</p>
  
  <ol>
  <li>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.</li>
  </ol>
  
  <p>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.</p>
  
  <ol start="2">
  <li>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.</li>
  </ol>