This website uses cookies. By clicking Accept, you consent to the use of cookies. Click Here to learn more about how we use cookies.
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- Revenera Community
- :
- InstallShield
- :
- InstallShield Forum
- :
- Re: Running Response Transform on other OS
Subscribe
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Subscribe
- Mute
- Printer Friendly Page
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Nov 16, 2009
11:45 PM
Running Response Transform on other OS
We’ve recently updated our packaging machines from WinXP x86 to Win7 X64 in order to be able to use more memory for our VMs.
What we’re now discovering is that if we create a response transform on these boxes, we’re unable to run that transform on WinXP boxes (the majority of our fleet currently).
I’ve tested creating the same response transform on WinXP x86, Win7 x86 and Win7 x64 and the only one that will run on Win XP is the WinXP x86 version. I’ve also tried updating Windows Installer to version 4.5, but it’s still not working. The reverse (a response transform created on WinXP running on Win7) does seem to work correctly.
Is this a know issue that’s going to be fixed, or is it a ‘feature’ that we’re just going to have to live with?
If the latter, what is Flexera’s policy on installing InstallShield on multiple PCs for use by the same packager, as I’m guessing that’s what we’ll have to do to work around this issue?
What we’re now discovering is that if we create a response transform on these boxes, we’re unable to run that transform on WinXP boxes (the majority of our fleet currently).
I’ve tested creating the same response transform on WinXP x86, Win7 x86 and Win7 x64 and the only one that will run on Win XP is the WinXP x86 version. I’ve also tried updating Windows Installer to version 4.5, but it’s still not working. The reverse (a response transform created on WinXP running on Win7) does seem to work correctly.
Is this a know issue that’s going to be fixed, or is it a ‘feature’ that we’re just going to have to live with?
If the latter, what is Flexera’s policy on installing InstallShield on multiple PCs for use by the same packager, as I’m guessing that’s what we’ll have to do to work around this issue?
(5) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Nov 17, 2009
10:32 AM
I think the licensing policy is approximately per-user per-machine, so what you describe probably wouldn't fly. That said, let's look at alternatives. If the transforms work when created one way and not the opposite, there's some relevant difference that's being captured in the transform files themselves. You can use MsiDiff or InstallShield to see what's different about what the transforms change, or can save a transformed MSI and compare the resulting files directly.
Chances are good there's a property set differently between the two, but there are other things could affect it. Once you know what's different, you should be able to use InstallShield to edit the response transform generated on Windows 7 such that it will work on XP.
Chances are good there's a property set differently between the two, but there are other things could affect it. Once you know what's different, you should be able to use InstallShield to edit the response transform generated on Windows 7 such that it will work on XP.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Nov 17, 2009
06:48 PM
Hi Michael,
Thanks for your response and suggestion. I used Orca to convert the MSI / MST combinations into MSIs and then compared the results with MSIDiff as you suggested.
There were a few differences where it seems that the MST created on Windows 7 has not added some properties that were created on Windows XP (see below).
<$Table "Property">
<$RowsDelete WHERE="`Property` = 'AS_HKCR_EXE'">
<$RowsDelete WHERE="`Property` = 'AS_OPTIMIZE_ENABLED'">
<$RowsDelete WHERE="`Property` = 'AS_OPTIMIZE_STATUS'">
<$RowsDelete WHERE="`Property` = 'DefragStatus'">
<$RowsDelete WHERE="`Property` = 'RDRBIG_9X'">
<$RowsDelete WHERE="`Property` = 'IS_MAJOR_UPGRADE'">
<$/Table>
Not sure what these properties do, but if I add them into the Windows 7 MST, it will now install.
The question is, why weren't these Properties created on Windows 7??
Thanks
Brett
Thanks for your response and suggestion. I used Orca to convert the MSI / MST combinations into MSIs and then compared the results with MSIDiff as you suggested.
There were a few differences where it seems that the MST created on Windows 7 has not added some properties that were created on Windows XP (see below).
<$Table "Property">
<$RowsDelete WHERE="`Property` = 'AS_HKCR_EXE'">
<$RowsDelete WHERE="`Property` = 'AS_OPTIMIZE_ENABLED'">
<$RowsDelete WHERE="`Property` = 'AS_OPTIMIZE_STATUS'">
<$RowsDelete WHERE="`Property` = 'DefragStatus'">
<$RowsDelete WHERE="`Property` = 'RDRBIG_9X'">
<$RowsDelete WHERE="`Property` = 'IS_MAJOR_UPGRADE'">
<$/Table>
Not sure what these properties do, but if I add them into the Windows 7 MST, it will now install.
The question is, why weren't these Properties created on Windows 7??
Thanks
Brett
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Nov 17, 2009
07:28 PM
Nope, I was wrong, it's not those Properties that are causing the problem.
I decided to remove them one at a time to work out which specific Property was the cause, but ended up removing all of them and the MSI / MST would still install.
I then sanity checked the original MST and again it failed to install. Using this same MST in Orca, I generated a new MST with no other changes and retested. This time the install proceeded correctly.
Note, all these changes were performed on the Windows 7 x64 box, so the problem appears to be the way that InstallShield 2009 is generating the MST??
I decided to remove them one at a time to work out which specific Property was the cause, but ended up removing all of them and the MSI / MST would still install.
I then sanity checked the original MST and again it failed to install. Using this same MST in Orca, I generated a new MST with no other changes and retested. This time the install proceeded correctly.
Note, all these changes were performed on the Windows 7 x64 box, so the problem appears to be the way that InstallShield 2009 is generating the MST??
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Nov 18, 2009
11:44 AM
Ahah, I didn't know this myself, but apparently until IS2010 the response transform took a schema value from the version of MSI on which it was running. Thus Windows Installer on XP would refuse to apply the transform that claims to require MSI 5 (from Windows 7). Applying and regenerating this transform with Orca seems to adjust the schema value, so is a fine workaround. It has also been fixed in IS2010 to use the schema version of the underlying MSI.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Nov 18, 2009
05:59 PM
Thanks again Michael. Nice to know the cause of the problem. Now to see if our AdminStudio 9 License and Maintenance allow us to update to IS2010.