The product that I'm working on requires that a type library file (suffix .tlb) be registered for internal COM communication between components to work correctly. On production machines this registration is performed by the InstallShield setup. On developer machines, however, we so far depended on the utility regtlibv12.exe to do the job.
While upgrading our dev environment to Visual Studio 2017 (previously Visual Studio 2013) we found out that regtlibv12.exe is no longer present. A quick search through the entire machine for regtlib*, tlb*.exe and other likely patterns did not yield any result. Also, my Internet search-fu did not produce anything useful - but I simply may have used the wrong keywords...
Do you know of any utility that is deployed with Visual Studio 2017 that can replace regtlibv12.exe? Anything that can be run from a PowerShell script is acceptable. Also acceptable is a hint for the relevant .NET API that I could use to code the registration process myself (I might even go so far as to try to p/invoke Win32 functions). Not acceptable are solutions that need to be run as part of the build process - I don't want the type library to be registered on the build server!
In case this is important: The .tlb file is generated from a .NET assembly with tlbexp.exe.
Following the suggestion by Joe Willcoxson (see OP comments), I ended up adding this snippet to our main executable manifest:
<file name="foo.tlb">
<typelib
tlbid="{EA4C1F13-2831-37CD-A94A-C761AF367506}"
version="1.0"
helpdir=""/>
</file>
As Joe mentioned, for this to work, the type library file has to be located in the same folder as the executable file that contains the manifest.
Specific to my situation, I was "lucky" because our main executable is as an out-of-process COM server, so when a client creates a COM object our main executable is launched as a separate process and our manifest takes effect. Had our COM object been in an in-process COM server, the client executable's manifest would have taken effect and I would have had to add the manifest snippet to the client executable.
As a final remark, I would like to add that this solution is probably not generally useful. What others could take away from here is that COM registration in the Windows registry can be obviated by a technique called "Isolated COM", which is also known as "Registration-Free COM". Whether you can take advantage of Registration-Free COM very much depends on how your COM servers and COM clients are deployed, and whether you have control over the manifests used by COM servers and clients.
As usual with COM, it's not a simple subject, but as a starting point for your research I can recommend the 2005 MSDN article Registration-Free Activation of COM Components: A Walkthrough, and its .NET companion Registration-Free Activation of .NET-Based Components: A Walkthrough.