Hi all!

I have an assignment at my work to make a package installation from a vendor MSI. The installation isn´t that hard. I have the vendor MSI package and the job is to make a .MST file that points into the right installation path. Then copy some specific files and create an additional folder etc.

The interresting and hard part is that from the same .MSI file I´m suppose to make an additional installation in another path on the same clients that is suppose to work together with the original installation (one original installation and one for education). I thought that if I just modify the vendor .MSI and generate a different Product ID it would solve the case. Just make a different .MST file with another Install path. But it doesn´t seem to work. The package thinks it´s already installed if the original MSI package is installed.

Any ideas how to proceed with this problem? I´m suppose to be done with this tomorrow (friday), so I´m a bit panicy :)

cheers
0 Comments   [ + ] Show Comments

Comments

Please log in to comment

Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.

Answers

0
Change the PackageCode (SummaryInformation RevNumber)
Answered 11/12/2009 by: AngelD
Red Belt

Please log in to comment
0
Thanks AngelD,

I´m sure it would work but now I just found out that if I actually use the original .MSI and use the .MST transform wizard in InstallShield none of the choices I make during the install gets saved down into the .MST file.
I choose install path, all users or current user and shortcut on desktop. Whatever I choose there the original (default) settings in the MSI will apply during the setup with the .MST file I just created.

Is this because the vendor .MSI is created with a tool that InstallShield doesn´t "understand" and therefore I can´t use the transform wizard?

I also tried to set "INSTALLDIR" as a variable in a .MST file but it didnt work. The program got installed in the default dir.

Help appreciated
Answered 11/12/2009 by: Agathorn
Senior Purple Belt

Please log in to comment
0
How are you executing the MSI and MST? Post your command line here.
Answered 11/12/2009 by: VBScab
Red Belt

Please log in to comment
0
msiexec.exe /i "<absolute path to msi file> TRANSFORMS="<absolute path to mst file>" /qb
Answered 11/12/2009 by: Agathorn
Senior Purple Belt

Please log in to comment
0
Good. Next stage is to log the install and see if the transform is being applied:msiexec.exe /i "<absolute path to msi file> TRANSFORMS="<absolute path to mst file>" /qb /l*v %temp%\somelogfilename.log The list of properties is gatherd together at the end of the log file. Other changes (e.g. feature states) will be recorded "in line".
Answered 11/12/2009 by: VBScab
Red Belt

Please log in to comment
0
I found out that the .MST file is actually being used but I partly solved the problem when I examined the log file and found out that the property [TARGETDIR] was being used as installdir.

But now when I change the packagecode, productcode and the upgradecode in the original MSI and save it in another place and make a separate .MST for this one. The MSI refuses to install itself, stating that "a never version of this program is already installed".
If I remove the action "FindRelatedProducts" it works but it seems as if there is a problem that should be solved instead of avoided.
When I search for the product code of the original MSI file in the tweaked one, I actually find a component who has that product code as it´s content. But it doesn´t work if I delete it, the component seems to be empty anyhow. But the MSI is unable to install itself anyway.

Any suggestions on how to duplicate the MSI into a package that is separate from the original one and can be installed parallell to the original?

EDIT: It should also be mentioned that I´m able to separately uninstall the the different MSI:s from a computer using "msiexec.exe /x <productcode>". Using the two different productcodes. So I don´t know why I have to delete the action FindRelatedProducts since all codes are different.
Answered 11/12/2009 by: Agathorn
Senior Purple Belt

Please log in to comment
0
There's probably some sort of PreventDowngrade check in the Upgrade Table, based on the old UpgradeCode that's stopping the install when another version is found.
Considering your situation it seems like you have no other choice but to change product code, package code, etc... but I don't know if I'd still consider it a vendor MSI based install after those kinds of changes.
Answered 11/12/2009 by: pjgeutjens
Red Belt

Please log in to comment
0
ORIGINAL: pjgeutjens

There's probably some sort of PreventDowngrade check in the Upgrade Table, based on the old UpgradeCode that's stopping the install when another version is found.
Considering your situation it seems like you have no other choice but to change product code, package code, etc... but I don't know if I'd still consider it a vendor MSI based install after those kinds of changes.


No I know. But when the vendor dont supply us with two different MSI:s then I don´t see another option I´m afraid. Beats doing a snapshot etc on the other installation just to avoid tampering with the original MSI.

Yes I saw the original upgrade code in the Upgrade Table so I hope removing those two entries will fix things.
Answered 11/12/2009 by: Agathorn
Senior Purple Belt

Please log in to comment
0
Everything seems to work now except that a shortcut to the application is placed on the current users desktop. I saw a variable named DESKTOP_SHORTCUT which I set to value "0" but this had no effect I´m afraid.

No biggie, I can delete the icon at distribution with ZenWorks but it´s annoying!
Answered 11/13/2009 by: Agathorn
Senior Purple Belt

Please log in to comment
0
The mere presence of a property, irrespective of its value, could be resolved as True if its value isn't explicityly tested. For example, a condition IF DESKTOP_SHORTCUT resolves as True if the value is '0', '1', or 'HolyCowBatman!'. However, IF DESKTOP_SHORTCUT=0 only resolves to True if the value is indeed '0'.

Try removing the property altogether via your transform. Alternatively, you could just remove the relevant entry in the Shortcut table.
Answered 11/13/2009 by: VBScab
Red Belt

Please log in to comment
0
Hi!

Actually there is no shortcut in the shortcut view in Install Shield. If we are talking about the same thing? The "Shortcuts" view under "System Configuration" in InstallShield?

Seems as if InstallShield isn´t able to identify the shortcut I assume. I tried to remove everything that had anything to do with shortcuts. But I´ll try again :)
Answered 11/13/2009 by: Agathorn
Senior Purple Belt

Please log in to comment
0
I was referring to the Shortcut table itself. You can view the MSI tables in IS's 'Direct Editor' view. However, it could well be that there is no "proper" s/c and that it's created by a Custom Action, which might use the DESKTOP_SHORTCUT property as its condition for execution. If that's the case, removing the property would stop that Custom Action from running. Again, you can view the CustomAction table in 'Direct Editor' view.
Answered 11/13/2009 by: VBScab
Red Belt

Please log in to comment
0
I deleted the custom action that set the shortcut on the desktop and finally this worked! Thanks for all the help!
Answered 12/03/2009 by: Agathorn
Senior Purple Belt

Please log in to comment
Answer this question or Comment on this question for clarity