Q:

COM References and TFS build definition

I have a C# project in which I have a COM Reference. It compiles fine when opened in VS 2013. But, it fails as part of TFS build definition.
TFS version : 2013
TFS Build Controller & Agent : 2013
VS version : 2013
The failure message says that it could not find the Interop dll. I cannot manually create the Interop dll and check-in into TFS because it would keep changing and I want my C# project to always take the udpated COM reference.
I tried the COMFileReference suggestion but it did not solve my issue. I even manually registered the COM dll using regsvr32 but still I am facing the issue.
Any help is highly appreciated.
Regards,
kvk1985

A:

A COM reference is the safest way to ensure that your program matches the actual installed component when you test your code.  The compiler will read the type library of the component, a very similar mechanism that's used for normal .NET assembly references. Except that the type definitions come from the type library instead of .NET metadata.
But has a disadvantage in your case, it can only work when the component is actually installed on the machine.  That probably did not happen on that build server.  That's fairly normal, the people that maintain build servers don't particularly like anybody messing with it.  And it is a maintenance headache, the build breaks when the devs update their machine with the latest version but forget to update the build server as well.  And old builds get to be hard to reproduce.
So installing the component on the build server is the Quick Fix.  If that's an insurmountable obstacle then somebody needs to run Tlbimp.exe on their machine.  That generates the interop assembly, it needs to be checked-in to source control.  And the project must be modified, remove the COM reference and add the reference to the generated interop library.  It will now build the same way on the build server and the dev machines.
That's of course brittle the other way, if a dev updates the component on his machine then there will be a mismatch with the interop assembly.  That can be a very ugly one, an E_NOINTERFACE runtime error if the COM vendor did it right, something excessively nasty like calling the wrong method, a stack imbalance or an AVE if he didn't.  Otherwise the exact same kind of failures that can occur if the user's machine doesn't have the right version of the component installed.  Standard DLL Hell.
You'll have to make the call yourself, there's no One Right Answer.

