This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(268.8, 37%, 36%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EMS%3C/text%3E%3C/svg%3E)
We have an application for which we are creating a new more modern installer using the Wix Toolset.
This application requires several files that from what I have read have been deemed by Microsoft as redistributable by applications.
Those files are comctl32.ocx, ComDlg32.ocx, mscomctl.ocx, mscomct2.ocx, msstdfmt.dll, tabctl32.ocx, and Tlbinf32.dll
We are trying to ensure that these files are properly installed as shared so that if our application, or another, were to uninstall them, they would not be removed until no application needs them any longer.
From what I can determine, this is apparently by using the same Component ID (Guid) for these files by each installer (separate one per file).
The issue is that I am unable to find what this Component ID should be.
We managed to scavenge Component IDs for these files from the registry of a machine that has them installed, but in most cases, more than one Component ID was identified.
The other way to approach this is to use a merge module, unfortunately, it seems that Microsoft does not provide that for these files.
Can anyone help with this? Have I posted this to the wrong place? If so, where should I post this?
Please help
I appreciate any information that can be provided.
Thank you.
Mark
Have I posted this to the wrong place?
Yes, not related to windows-app-sdk
if the application is in C++, it could be C++ Tag for example, or vs-general maybe
Have you come to any decision about how you're going to proceed?
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(51.2, 83%, 14%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EA%3C/text%3E%3C/svg%3E)
You may get it from latest update for VB60SP6
https://www.microsoft.com/en-us/download/details.aspx?id=50722
open the msi with Orca or InstEd
except Tlbinf32.dll, i don't know what's the source for it
Thank you for this information.
That is the download for kb3096896 which is dated January 12, 2016
It expands to the full url when you go there.
Although I have not opened that update in any editor, based on the information in the registry, that seems to be one of the two component id we got from the registry.
The problem is that the other component id is apparently from Office 2010, Visual Studio 2015, and other similar apps, as well as QuickBooks, and Crystal Reports, so I really was not sure what the correct value should be.
It seemed odd to me that the Component IDs for shared files would have changed, especially for those specified by Microsoft installers.
Because of that I was unsure how to correctly do this.
Another odd thing is that the support article mentions only two of those files (Comctl32.ocx, and Mscomctl.ocx), however, the registry has the rest of them, except for the unsupported tlbinf32.dll.
I appreciate any feedback you, or anyone can give.
Thank you
Tlbinf32.dll is an unsupported VB6 runtime file -- visual-basic-6-support-policy
I am aware of that regarding Tlbinf32.dll. I wish I had an alternative for that, but have not found one as yet. Unfortunately, I really haven't been given any time to look for it either.
As far as I can tell tlbinf32.dll was distributed with VS6 and VB6 and was also updated with related service packs. Perhaps you can test to see if those products are installed and/or do a file search for the dll. In my ancient 32-bit Win2K VM it was installed in the System32 folder. When I peeked inside the VS6SP6.exe iinstaller I did not see any .msi files. The tlbinf32.dll file was contained inside the vs6sp61.cab file and the main application seemed to be acmsetup.exe.
Since this dll seems to be governed by the products that installed it are you certain it is actually redistributable?
Perhaps its time to modernize the code to remove the dependency on tlbinf32.dll
I am pretty sure that I read that it was on a Microsoft webpage years ago, but I would not be surprised if that page is now gone with Microsoft removing and changing everything.
There is actually an 8 year old nuget package for that dll (https://www.nuget.org/packages/TypeLibInformation/) with the source here: https://github.com/NetOfficeFw/TypeLibInformation
According to C:\Program Files (x86)\Microsoft Visual Studio\VB98\REDIST.TXT the tlbinf32.dll is part of REDISTRIBUTABLE CODE - STANDARD which I take it to mean that it IS redistributable, even though it is now no longer supported.
As I mentioned before, I am unsure of a way to replace this file at this time, that is without a full rewrite to .NET which is just not a possibility at this time. We still need to be able to support COM and to dynamically call methods in COM objects from an exe that was created with VB6.
Unfortunately, replacing the exe with a .NET app will not work at this time. They initialize the process differently which causes some COM dlls to fail when running under a .NET exe. If I knew what the differences were and how to get the .NET exe to initialize like the VB6 one, then perhaps we could invest the manpower to convert, however we would still need to dynamically call methods in COM dlls, and I do not know how to do that currently. When calling .NET dlls from .NET it is simple to use reflection to accomplish that.
Have you considered using registration-free COM with tlbinf32.dll so that you can install your own private-use copy and avoid having to deal with the registry for COM? I'm not intimate with VB6 but I think I remember reading that it does support registration-free COM.
I have not actually.
I am somewhat familiar with how to do it in .NET, but based on that, it looks like it would be a pain if it is even possible for us to do it in VB6.
You may find this of interest - Registration-Free Activation of COM Components: A Walkthrough.
Only you can decide if registration-free COM is more or less painful than resolving your .msi shared component questions.
The old msdn magazine article about tlbinf32.dll is at visual-basic-inspect-com-components-using-the-typelib-information-object-library. There is a related sample but of course the link doesn't work.
I found the article code from web.archive.org and used my old Win2K VM to build the sample VB6 program (TypeLibraryExplorer.exe).
Then I copied the sample program executable, TLBINF32.DLL, MSCOMCTL.OCX and COMDLG32.OCX to a folder on my Win10 21H1 system. I placed manifests for the above into the same folder. No COM registration was performed. The sample program executed on my Win10 system as seen below -
If you want to try it, I uploaded the VB6 code and the manifests I used to OneDrive - https://1drv.ms/u/s!AmnqrCFBv4nDgiH-e6Fhbf6Lz8Pj?e=sDh4RQ
I guess there is no way to embed those manifest files.
That is quite different from how I did registration free com in .NET.
I didn't try to embed the manifests. However, I expect that mt.exe (manifest tool) would be able to embed them.
The manifest tool was able to embed manifests in the VB6 executables. But it seems that when creating activation contexts from embedded manifests the system will only search for DLLs. So it doesn't find the two .OCX files and an SXS error results. I worked around this by merging the manifest information for COMDLG32.OCX and MSCOMCTL.OCX into the manifest that was embedded in TLBINF32.DLL. The manifest embedded in TypeLibraryExplorer.exe was adjusted accordingly. Success!
