MSI upgrade issues
Hi!
Just when I thought I had the windows installer upgrade table etc figured out I ran into a problem.
I have a vendor MSI with a .MST (.MST not developed by myself but some1 else, not the vendor though). Now we have seen that one shortcut is wrong and one .dll needs to be registered.
My thought was to up the version of the program slightly (the very last digit of the code X.XX.XXX1 when it was X.XX.XXX0 before), change the product code and enter the upgrade table manually to uninstall all previous versions. (change all this in the .MST. This should be possible without tampering with the original vendor MSI, right?)
My issue though is that when I run the .msi with the new .mst the installer simply uses the cached msi from C:\WINDOWS\Installer.
The verbose log says:
Original package ==> <PATH TO MY MSI>
Package we´re running from ==> C:\Windows\installer\431897.msi
I have checked and FindRelatedProducts and RemoveRelatedProducts do exist in the installation execute sequence (I install with this command: "msiexec.exe /i <msi-filename> \qb!+".
I thought I maybe had the upgrade table wrong but I have tried a lot of combinations. The one I tried just now is:
Upgrade code: <same code as previous msi +mst>
VersionMin: NULL
VersionMax: Previous version of the package to upgrade from
Language: NULL
Attributes 512
ActionProperty: ISACTIONPROP7 (the property was already under secureCustomProperties to my dazzlement)
Does anyone know something I can try? It seems as the vendor MSI is from Wise. I work in InstallShield2010.
Just when I thought I had the windows installer upgrade table etc figured out I ran into a problem.
I have a vendor MSI with a .MST (.MST not developed by myself but some1 else, not the vendor though). Now we have seen that one shortcut is wrong and one .dll needs to be registered.
My thought was to up the version of the program slightly (the very last digit of the code X.XX.XXX1 when it was X.XX.XXX0 before), change the product code and enter the upgrade table manually to uninstall all previous versions. (change all this in the .MST. This should be possible without tampering with the original vendor MSI, right?)
My issue though is that when I run the .msi with the new .mst the installer simply uses the cached msi from C:\WINDOWS\Installer.
The verbose log says:
Original package ==> <PATH TO MY MSI>
Package we´re running from ==> C:\Windows\installer\431897.msi
I have checked and FindRelatedProducts and RemoveRelatedProducts do exist in the installation execute sequence (I install with this command: "msiexec.exe /i <msi-filename> \qb!+".
I thought I maybe had the upgrade table wrong but I have tried a lot of combinations. The one I tried just now is:
Upgrade code: <same code as previous msi +mst>
VersionMin: NULL
VersionMax: Previous version of the package to upgrade from
Language: NULL
Attributes 512
ActionProperty: ISACTIONPROP7 (the property was already under secureCustomProperties to my dazzlement)
Does anyone know something I can try? It seems as the vendor MSI is from Wise. I work in InstallShield2010.
0 Comments
[ + ] Show comments
Answers (17)
Please log in to answer
Posted by:
mekaywe
13 years ago
using Wise/InstallShield will not create any problem. I suppose you are using the command "msiexec /i <msipath> <mstpath>" as the command you posted doesn't have reference to transform.
Probably you can try following ways:
1. move RemoveExistingProducts CA to just below CostInitialize
2. remove the option "migrate feature states" in upgrade table
3. Include max version in upgrade table entries
In MSI perspective I suppose that Upgrade should/will generally happen only if there is change in major version, since you changed minor version in MST. Upgrade is not happening.
Probably you can try following ways:
1. move RemoveExistingProducts CA to just below CostInitialize
2. remove the option "migrate feature states" in upgrade table
3. Include max version in upgrade table entries
In MSI perspective I suppose that Upgrade should/will generally happen only if there is change in major version, since you changed minor version in MST. Upgrade is not happening.
Posted by:
murali.bhat
13 years ago
If your problem is not solved yet, try changing the version number from X.XX.XXX0 to X.XX.X1XX0
I suppose msi's version format should be aa.bb.cc
I suppose msi's version format should be aa.bb.cc
Posted by:
anonymous_9363
13 years ago
You're not upgrading anything, though, are you? If you were changing the DLL for a higher version, then I'd expect the upgrade to proceed.
Use REINSTALL and REINSTALLMODE.
Use REINSTALL and REINSTALLMODE.
Posted by:
Agathorn
13 years ago
Well I thought if I change the version the old version would uninstall before the new version gets installed. Regardless of what I change in the package.
The change in the package is a new shortcut in the startmenu. The regsvr.exe on the dll will take place in CM.
I will try to change the version number into a higher one and see if it works better. It seems risky though if the vendor releases new code that has a lower version then my new "modded" MSI.
The change in the package is a new shortcut in the startmenu. The regsvr.exe on the dll will take place in CM.
I will try to change the version number into a higher one and see if it works better. It seems risky though if the vendor releases new code that has a lower version then my new "modded" MSI.
Posted by:
Agathorn
13 years ago
Yes I use the transform in the way you said mekaywe. I forgot that part in the installstring. I have also tried to change directly in the MSI with the same result.
I just tried to change the version from X.1X.XXXX to X.20.XXXX with the same result. The installer uses the cached MSI on the computer and "installs" the old version all over again.
Ill try the other suggestions in a while.
I just tried to change the version from X.1X.XXXX to X.20.XXXX with the same result. The installer uses the cached MSI on the computer and "installs" the old version all over again.
Ill try the other suggestions in a while.
Posted by:
pjgeutjens
13 years ago
David,
I'm thinking you're stuggling with the old "can't reinstall an MSI with a different MST" issue. The fact that the "old" msi is still being dug out of the Windows/Installer folder to me indicates that the original without the product code change is being used, disregarding the changes in the MST.
That being said it's not a good idea to change the productcode on a vendor msi in my book. Like Ian suggested, I'd leave the product code in place and use UNINSTALL and REINSTALL properties on the commandline for your new MSI.
Rgds,
PJ
I'm thinking you're stuggling with the old "can't reinstall an MSI with a different MST" issue. The fact that the "old" msi is still being dug out of the Windows/Installer folder to me indicates that the original without the product code change is being used, disregarding the changes in the MST.
That being said it's not a good idea to change the productcode on a vendor msi in my book. Like Ian suggested, I'd leave the product code in place and use UNINSTALL and REINSTALL properties on the commandline for your new MSI.
Rgds,
PJ
Posted by:
anonymous_9363
13 years ago
I completely overlooked the fact that this is a vendor MSI. It's a Really Bad Idea to change vendor's ProductCode.
Also, using RegSvr32 to register DLLs is another Really Bad Idea. Use the advertising tables.
Also, using RegSvr32 to register DLLs is another Really Bad Idea. Use the advertising tables.
Posted by:
dreyer
13 years ago
The OP did not mention changing the PACKAGE CODE. You cannot use the upgrade table unless you actually change the PACKAGE CODE.
If you change the package code, product code and product version and use the upgrade table you can make that work just fine. Technically there's nothing wrong with doing this, but you can potentially run into problems further down the line when the vendor comes out with a new version you want to upgrade to. Though I find the most negative aspect of doing this is that you have to make a change to the original vendor package and now its 'integrity' is perhaps broken as you cannot change the package code with an .mst. When using the upgrade table you cannot change the product code either (if you don't intend to use MSI upgrade you can change a product code in the .mst just fine).
As already mentioned by VBScab it's probably best to use the REINSTALL and REINSTALLMODE functionality and push out the updated .mst to the clients in this case.
If you change the package code, product code and product version and use the upgrade table you can make that work just fine. Technically there's nothing wrong with doing this, but you can potentially run into problems further down the line when the vendor comes out with a new version you want to upgrade to. Though I find the most negative aspect of doing this is that you have to make a change to the original vendor package and now its 'integrity' is perhaps broken as you cannot change the package code with an .mst. When using the upgrade table you cannot change the product code either (if you don't intend to use MSI upgrade you can change a product code in the .mst just fine).
As already mentioned by VBScab it's probably best to use the REINSTALL and REINSTALLMODE functionality and push out the updated .mst to the clients in this case.
Posted by:
mekaywe
13 years ago
what you can do is Uninstall the app which is installed on the machine and then proceed with new installation. You can write a script which can perform these two tasks in one shot, ofcourse you need to have error tapping before you start with new installation.
Posted by:
Agathorn
13 years ago
No using reinstall and reinstallmode doesn´t seem to work. I use: "msiexec.exe /i <msi-file> TRANSFORMS=<mst-file> REINSTALL=ALL REINSTALLMODE=VAMS /qb+". I also tried VOMUS with same result.
But I found this thread which seems to deal with the exact same problem I have. And the "solution" was to change registry keys to point to the new MST or to uninstall the current application and install the new one with the new mst. So there isn´t a more "proper" way of doing this?
http://www.appdeploy.com/messageboards/printable.asp?m=48858
As far as package code goes, there isn´t one. Really strange but I cant find the entry. I have searched for one in the direct editor as well.
Why is it a bad idea to use regsvr.exe? Is it the fact that it doesnt get "deregistered" during uninstallation?
But I found this thread which seems to deal with the exact same problem I have. And the "solution" was to change registry keys to point to the new MST or to uninstall the current application and install the new one with the new mst. So there isn´t a more "proper" way of doing this?
http://www.appdeploy.com/messageboards/printable.asp?m=48858
As far as package code goes, there isn´t one. Really strange but I cant find the entry. I have searched for one in the direct editor as well.
Why is it a bad idea to use regsvr.exe? Is it the fact that it doesnt get "deregistered" during uninstallation?
Posted by:
dreyer
13 years ago
ORIGINAL: Agathorn
No using reinstall and reinstallmode doesn´t seem to work. I use: "msiexec.exe /i <msi-file> TRANSFORMS=<mst-file> REINSTALL=ALL REINSTALLMODE=VAMS /qb+". I also tried VOMUS with same result.
But I found this thread which seems to deal with the exact same problem I have. And the "solution" was to change registry keys to point to the new MST or to uninstall the current application and install the new one with the new mst. So there isn´t a more "proper" way of doing this?
http://www.appdeploy.com/messageboards/printable.asp?m=48858
As far as package code goes, there isn´t one. Really strange but I cant find the entry. I have searched for one in the direct editor as well.
Why is it a bad idea to use regsvr.exe? Is it the fact that it doesnt get "deregistered" during uninstallation?
The reason it's using the local version of the msi/mst is because you havent updated the package code. It's not really strange and there is a package code, you just don't know where to look. The package code is not stored in the tables, it's stored as a property in the summary information stream, which is kind of like the file header.
Use a proper tool, like InstEdit and goto Tables->Summary Info (tables as in File, Edit, View, Tables menu).
Posted by:
Agathorn
13 years ago
interesting dreyer, you are correct. But I´m unable to change it though, using the .MST. And it seems like a bad idea to change it if I´m not going to change the productcode, version etc either.
If I´m going this path I have to change the package-code in the vendor MSI and the product code in the vendor msi or using a mst and then I´m down the path where I have to "correct" these codes with every new release from the vendor so it works ...
If I´m going this path I have to change the package-code in the vendor MSI and the product code in the vendor msi or using a mst and then I´m down the path where I have to "correct" these codes with every new release from the vendor so it works ...
Posted by:
anonymous_9363
13 years ago
Why is it a bad idea to use regsvr.exe?...because it's actually RegSvr32.EXE? :-)
Seriously, the biggest single reason is that, if the DLL/OCX has dependencies and those dependencies are not present, registration will fail. The same applies to 'MSIEXEC /Y [filename]'. Your packages should be totally discrete and stand-alone. There is obviously an argument that packages should also check for such dependencies and branch accordingly if they're not present.
Posted by:
Agathorn
13 years ago
ok thanks
We will uninstall the current installation of the program and reinstall it again. Seems to work best.
We will uninstall the current installation of the program and reinstall it again. Seems to work best.
Posted by:
Agathorn
13 years ago
mekaywe: Well the best solution seems to be uninstall and install if you dont want to either:
1. Change the Vendor MSI which is a big no no
2. Change the version of the program even though there are not really a real version upgrade
So what are my options?
1. Change the Vendor MSI which is a big no no
2. Change the version of the program even though there are not really a real version upgrade
So what are my options?
Posted by:
Rheuvel
13 years ago
@mekaywe: he's learned 2 things from this, so I wouldn't say wasted ;)
Rating comments in this legacy AppDeploy message board thread won't reorder them,so that the conversation will remain readable.