Register textpipeengine.dll with regsvr. (We would do that by default, but a lot of users have their systems locked down by IT so that they can't register any COM dll's, and trying to causes the installer to fail.)
So many wrongs .. where to begin ...
textpipeengine.dll does *NOT* have to registered.
It is a registration-free COM component (also known as isolated COM).
textpipeengine.dll is provided by another company (datamystic) and TPIPE.exe is jpsoft's "interface" between this DLL and TCC (although TPIPE.exe can also be run standalone, without TCC).
The only reason textpipeengine.dll has to be registered now (it was never needed in the past) is because of programming errors in the current version(s?) of TPIPE.exe.
That's why replacing TPIPE.exe with an older version "repairs" it: now TPIPE can be run *without registering the DLL*.
Registering this DLL is a "Plan B" fail-save mechanism of Window to be able to address the DLL in a different way.
There is no such thing as COM blocking.
COM components are a core functionality of modern Windows. If it is blocked, most applications (including Office) and large parts of the operating system won't work anymore.
On my systems I have blocked access to "my" COM components from external systems (that is a often overlooked security leak: a lot of COM components have lousy security settings, which makes it possible to access files and functions on my system from any system). But I seriously doubt that a lot of companies/people have it setup this way. Or even heard about it ...
But registering a DLL requires administrative rights. In most companies the employees run their programs as a "regular" user. That's why the DLL should be registered during installation (*if* it needs registration)
Installer fails on registering the DLL?
It took me literally less than 10 minutes to extract the MSI from the installer, break open the MSI (using Orca), add DLL-registration functionality, save the MSI and run the extracted MSI ( yes, that is possible: msiexec.exe /i tcmd.x64.msi SETUPEXEDIR="." )
This registered the DLL on install and unregistered it on uninstall without any problems whatsoever (and my system is probaly more locked-down than most).
Ergo: the Windows Installer technology can handle this situation without issues. If it does fail, it is most likely a human error.
a lot of users have their systems locked down by IT
I'm probably biased, but I can't imagine Take Command being used in companies very much...
Part of my job is to advise companies about their application landscape.
Take Command is one of those applications I would advise against using it in a corporate environment.
Personal use: fine; using it as part of your company's workflow: deprecate it as soon as possible.