How to inspect an MSI's embedded instances for product codes?
June 9, 2011 1:23 PM Subscribe
How can one inspect an MSI to see what embedded transforms it defines?
I've got a Wix-defined, msbuild-built MSI with 20 embedded transform instances inside. I know the instance's Id for each instance. Is it possible for me to get the product code for a given Id from the MSI in some way based on this information?
For reasons beyond my control and too banal to go in to, my employer--a service bureau of sorts--wants to use embedded transform MSIs in their automated deployment system. The first step in this process is to uninstall the current build. The deployment system is aware of the instance id, but does not know what product code that id maps to. Any call to msiexec to perform an uninstall appears to need the product code of the instance.
I have pretty free reign in terms of what I can use to get at this. My requirements are that it runs without human input and be callable from a .bat file. I've played with msiexec and msidb.exe to no avail. I've opened the MSI in Orca but cannot even find where it stores the transforms, much less how to address them. The current strategy is to write and maintain a separate index/lookup in the batch file or a standalone C# console app but I'd love to not duplicate the data for the usual reasons.
I've got a Wix-defined, msbuild-built MSI with 20 embedded transform instances inside. I know the instance's Id for each instance. Is it possible for me to get the product code for a given Id from the MSI in some way based on this information?
For reasons beyond my control and too banal to go in to, my employer--a service bureau of sorts--wants to use embedded transform MSIs in their automated deployment system. The first step in this process is to uninstall the current build. The deployment system is aware of the instance id, but does not know what product code that id maps to. Any call to msiexec to perform an uninstall appears to need the product code of the instance.
I have pretty free reign in terms of what I can use to get at this. My requirements are that it runs without human input and be callable from a .bat file. I've played with msiexec and msidb.exe to no avail. I've opened the MSI in Orca but cannot even find where it stores the transforms, much less how to address them. The current strategy is to write and maintain a separate index/lookup in the batch file or a standalone C# console app but I'd love to not duplicate the data for the usual reasons.
Orca is a good free MSI editor which should allow you to change values as well if needed.
posted by samsara at 1:54 PM on June 9, 2011
posted by samsara at 1:54 PM on June 9, 2011
Ah posted too soon, I see you've used Orca already. ignignokt is right that you should be able to find the product code in the registry. In most cases you can also uninstall without needing the Product ID as long as you reference the original MSI. This might be a bit of a ad hoc workaround, but would your company be able to purchase a 3rd party solution such as Admin Studio? Seems that the current setup is not as flexible as it needs to be for automation.
posted by samsara at 2:00 PM on June 9, 2011
posted by samsara at 2:00 PM on June 9, 2011
Is it possible for me to get the product code for a given Id from the MSI in some way based on this information?
Definitely should be stored in the registry. The path name escapes me, but it's there.
I've opened the MSI in Orca but cannot even find where it stores the transforms, much less how to address them.
Never dealt with embedded transforms (I confess to thinking "why would anyone do that?" as I read your question), but if I had to guess where they were in an msi, I would suppose they could be compressed in the binary table (there are ways to extract resources from the binary table should you need to). Again....never tried to embed mst's before....just a guess.
posted by PsuDab93 at 2:29 PM on June 9, 2011
Definitely should be stored in the registry. The path name escapes me, but it's there.
I've opened the MSI in Orca but cannot even find where it stores the transforms, much less how to address them.
Never dealt with embedded transforms (I confess to thinking "why would anyone do that?" as I read your question), but if I had to guess where they were in an msi, I would suppose they could be compressed in the binary table (there are ways to extract resources from the binary table should you need to). Again....never tried to embed mst's before....just a guess.
posted by PsuDab93 at 2:29 PM on June 9, 2011
Response by poster: I've been digging through the registry and in HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\ and see a few hives that list out installed products by product code GUID. Product code GUID --> install location (and other info, but not instance id oddly enough) lookups are easy enough. Unfortunately I need to go the other direction.
samsara: Running
PsuDab93: I've confessed to thinking "why would anyone do that" many times since this I inherited this turd. I think the bet is that my time throwing this together will cost less than the number of VMs we'd have to roll out to install each customer's application suite on a separate machine. Thanks for the clue about the binary table. I haven't found a way to tease information out of that yet, but since the information isn't anywhere else, it's probably locked away in there.
I'll look around a bit more but am guessing my time will be better spent cobbling together something on the build side that injects lookup information from our wix include file into the batch file that controls the deployment. Info will still be in two places, but at least we're only managing it once this way.
posted by Fezboy! at 3:45 PM on June 9, 2011
samsara: Running
msiexec /u against an MSI works for a normal install. For a transform install, there doesn't appear to be a way to reference a particular embedded instance. Hence the need for the product code GUID. A naked msiexec /u foo.msi complains that the product isn't installed (because the "default" instance isn't installed).PsuDab93: I've confessed to thinking "why would anyone do that" many times since this I inherited this turd. I think the bet is that my time throwing this together will cost less than the number of VMs we'd have to roll out to install each customer's application suite on a separate machine. Thanks for the clue about the binary table. I haven't found a way to tease information out of that yet, but since the information isn't anywhere else, it's probably locked away in there.
I'll look around a bit more but am guessing my time will be better spent cobbling together something on the build side that injects lookup information from our wix include file into the batch file that controls the deployment. Info will still be in two places, but at least we're only managing it once this way.
posted by Fezboy! at 3:45 PM on June 9, 2011
Perhaps get a forum account at Appdeploy and ask there? This might be a rare scenario, but the folks there seem to know installers inside out...worth a shot.
posted by samsara at 4:50 PM on June 9, 2011
posted by samsara at 4:50 PM on June 9, 2011
This thread is closed to new comments.
posted by ignignokt at 1:33 PM on June 9, 2011