Installing shared Microsoft component files.

[mdell-seradex]

Our application uses several Microsoft dlls for which I can find no merge modules, but Microsoft's documentation has stated that we have permission to deploy them with our application. The point of ensure that they are shared is to ensure that only the latest version is installed, and it is not removed if another app needs it.
My understanding is that the current way to have an installer treat them as shared files is to use the same Component ID that other installers do.
The issue is that I have not been able to determine what those should be and am unsure how to setup the Wix files for that.

The specific files in question are comctl32.ocx, ComDlg32.ocx, mscomctl.ocx, mscomct2.ocx, msstdfmt.dll, tabctl32.ocx, and Tlbinf32.dll
I do realize that the last file is technically no longer supported by Microsoft, but we have not found a good replacement for it.

We managed to create an application to scavenge Component IDs from the registry of a system that already had these installed, unfortunately, in many cases, it found more than one Component ID for a file, all in the same location.

I appreciate any and all information that can be provided.

Thank you
Mark

[robmen]

You really should ask Microsoft. They own the files and should provide that information (or a Merge Module so you don't have to worry about it).

[mdell-seradex]

@robmen, I am not sure how or where I would ask them this as it seems that all the forum sites are managed by designated people in the community as opposed to actually Microsoft employees that have the required knowledge. It feels rare that Microsoft employees respond to the community.
Do you have any suggestions? Most places that I can think of seem like this kind of question would be marked as off-topic.

Also, are we actually going the correct way with this?

I really appreciate any help that can be provided.
Thank you
Mark

[robmen]

You're looking for the right thing but from the wrong people. Maybe someone here has had the same experience you had and knows the answer but, ultimately, the answer (the Component Guids to use for these Microsoft files+registry keys) doesn't come from us... it comes from Microsoft (even if Microsoft doesn't make it easy to find or ask for such information).

[mdell-seradex]

@robmen Thank you for letting me know that I am at least attempting to pursue the right information.

Also, I recall now reading something about the Component ID we specify in the Wix installer files being merged with the Product ID to create a new final Component ID when the msi is built, which would then not actually match the shared Component ID (Guid). Is this something to be concerned about, or did I simply misunderstand what I had read?

Beyond that, I will leave this open in case someone else can provide additional insight on this, even if just where to go.

Thank you for your assistance Rob.
It is greatly appreciated.
Mark

[robmen]

Also, I recall now reading something about the Component ID we specify in the Wix installer files being merged with the Product ID to create a new final Component ID when the msi is built, which would then not actually match the shared Component ID (Guid). Is this something to be concerned about, or did I simply misunderstand what I had read?

Don't know exactly what you read but the Product/@id (ProductCode) and Component/@guids are completely independent concepts. That doesn't parse for me.

[mdell-seradex]

I recall someone saying that they created a custom build to change the condition it uses for the guid so it did not do that.
I believe I found the issue posting. oleg-shilo/wixsharp#644 I have probably misunderstood it.
Looking at it again, it was probably specific to that tool, and not the Wix Toolset itself.
I'm a Wix Toolset newbie, so I probably just got my wires crossed... 🙂
I don't think I realized the difference at the time.