What happened to regtlibv12?

Refer to Hans' excellent answer to the question as posed; this answer explains how to get hold of the aforementioned executable.

1. Install 7-Zip from https://www.7-zip.org/download.html
2. Download lessmsi/Less MSIérables from https://github.com/activescott/lessmsi/releases

(Or you can use chocolatey to install both of the above: package names are 7zip and lessmsi respectively.)

3. Download the .NET Framework 4.0 Standalone Installer from https://www.microsoft.com/en-gb/download/details.aspx?id=17718
4. Use 7-Zip to open the downloaded dotNetFx40_Full_x86_x64.exe from the previous step, extract the files netfx_Core_x64.msi and netFxCore.mzz to a temporary directory
5. Use lessmsi to open netfx_Core_x64.msi, scroll down the file list and select regtlibv12.exe (the one with Component = regtlibv12_exe_amd64 for an x64 system, the other one for x86, or both if you need both) and click the "Extract" button
6. Browse for and select the directory you want to extract the files to, click OK
7. Et voila, you now have regtlibv12.exe!

• Note: I am not a lawyer and am unaware if the above violates any laws, nor can I be held liable if it does and gets you into trouble. At the very least, do not redistribute regtlibv12.exe (regardless of the fact that doing so would be illegal, if you think you need to - you either don't, or your software has big problems).

It was never part of the framework. And it is entirely undocumented. There is however a very consistent rumor that it is, lots of programmers have found it in their v2.0.50727 or v4.0.30319 directories and figured out that it could solve registration problems. Lots of forum posts mention it.

The exact way it shows up in those folders is hard to reverse-engineer, the only pattern I've seen is that it will be there when you install the framework yourself. And won't be there when the framework is pre-installed on the machine. Which somewhat makes sense, there are several .tlb files in the framework directory that need to be registered. They contain type info for .NET [ComVisible] types that client code may have a dependency on. The normal way type libraries get registered does not apply for those .tlb files since they are not embedded in a regular COM server. With the additional guess that the tool isn't needed in a pre-installed version of .NET because the registration info is rolled-up into the regular Windows setup.

If you've gotten yourself into a dependency on the tool then you can't do much beyond copying the .exe from another machine. Or tackle the reason you need to use it from the other end so you don't need it anymore:

• it is a workaround for forgetting to use the /tlb option with Regasm.exe. That may produce a TYPE_E_CANTLOADLIBRARY error at runtime when client code tries to use a COM interface from another thread. The type library provides the type info that the standard marshaller needs to marshal the arguments of the method. Use the /tlb option to fix that.

• it is a workaround for getting COM servers to show up in the Project + Add Reference, COM tab. That tab lists registered type libraries. It is however not a proper workaround, other than on build servers, you can compile your code but you can't run it since the registration is not complete. The proper way to do it is by using the author's provided installer or by using Regsvr32.exe in a pinch so both the type library and the CLSID keys get registered.

• it is a workaround for COM servers that don't register their type library. Similar as above, but registering type libraries is optional and typically only required on your dev machine, not on the machine that runs the server. Most tools that can consume type libraries have a way to add them explicitly rather than depend on the TypeLib registry key. So does the Visual Studio IDE, you can use the Browse tab instead to select the .tlb file directly.