Software Deployment

Piotr, check out this thread http://itninja.com/question/installshield-vs-wise-for-repackaging027

It contains all the information you need - or links to that information - regarding upgrade types, version numbers and Product Codes.

FYI, it looks like the forum software does not like a space at the end of a link as it is above. I've corrected the error message it was returning, but now it just thinks it cannot find the message. Be sure to strip any trailing spaces off links to avoid this situation.

http://itninja.com/question/installshield-vs-wise-for-repackaging027

PS: I know, I could "trim" the value, but the forum software is rather complex so unless there is a larger scale problem I'm resolved not to risk breaking it [;)]

VBScab, I already did the changes that are supposed to be don ei: Prod, Package and upgrade code in moth mst (wise) and msi (orca). Now it just installes the installation together with the previous version, I men it don't remove the previous version, but I have it as an upgrade in the new version....

Help pls, if you can...

kindly,
Piotr

OK, it sounds like you know what you're doing so, the next obvious question is, what does a verbose log tell you?

Also, does your MSI include the built-in RemoveExistingProducts action? A lot of vendors remove this action or move it to bizarre places.

ORIGINAL: bkelly
PS: I know, I could "trim" the value, but the forum software is rather complex so unless there is a larger scale problem I'm resolved not to risk breaking it [;)]Coward! The only version of ASP Playground I have has obfuscated code so I can't help you (ASP is another of my play-things...)

hmmm hehe yep...no RemoveExistingProduct action in the msi... How do I add that one manually VBScab?

kindly,
Piotr

Generally speaking, it goes right at the end of that sequence but depending on what else your MSI is up to, you may need to move it around.

It will be quicker to add it manually using Orca or InstEdit. It goes into the InstallExecuteSequence table.

If using Wise:
- go to the 'MSI Script' page
- select the 'Execute Immediate' tab
- scroll down to the bottom, past the 'InstallFinalize' action
- click the 'Standard' tab, at the bottom of the 'Actions' page.
- The second-from-bottom action should be 'RemoveExistingProducts'. Double-click it.
- Compile your MSI and test

okey thanks! Should have known the Removeexistingproducts thing.... made the changes but it still doesn't work?!?!

I made an empty package, with the same codes as in my new version (that doesn't work)...and this one works perfectly....?!? I tried to put the RemoveExistingProducts after the Installfinilized, after the Installinitialize and somwhere in the middle. When putting it in the middle i get an msi-error 2613 so it sure tries to do something....

Could there be a msi / mst problem or something?

any ideaes?
kindly,
Piotr

AppDeploy's MSI Error look-up page http://www.appdeploy.com/msierrors/ tells us:

Windows Installer Error 2613 RemoveExistingProducts action sequenced incorrectly.

In which sequence did you put the action?

hi...yes I read the errorcode... It was in the Execute Immediate somwhere between installinitialize and installfinilize

kindly,
Piotr

This shows you how often I fuss with this action...there are restrictions on where it can appear. This is from MSI.CHM:

RemoveExistingProducts Action
The RemoveExistingProducts action goes through the product codes listed in the ActionProperty column of the Upgrade table and removes the products in sequence by invoking nested installations. For each nested installation the installer sets the ProductCode property to the product code and sets the REMOVE property to the value in the Remove field of the Upgrade table. If the Remove field is blank, its value defaults to ALL and the installer removes the entire product.


The installer only runs the RemoveExistingProducts action the first time it installs a product. It does not run the action during a maintenance installation or uninstallation.


Sequence Restrictions

The RemoveExistingProducts action must be scheduled in the action sequence in one of the following locations.


Between the InstallValidate action and the InstallInitialize action. In this case, the installer removes the old applications entirely before installing the new applications. This is an inefficient placement for the action because all reused files have to be recopied.
After the InstallInitialize action and before any actions that generate execution script.
Between the InstallExecute action, or the InstallExecuteAgain action, and the InstallFinalize action. Generally the last three actions are scheduled right after one another: InstallExecute, RemoveExistingProducts, and InstallFinalize. In this case the updated files are installed first and then the old files are removed. However, if the removal of the old application fails, then the installer rolls back both the removal of the old application and the install of the new application.
After the InstallFinalize action. This is the most efficient placement for the action. In this case, the installer updates files before removing the old applications. Only the files being updated get installed during the installation. If the removal of the old application fails, then the installer only rolls back the uninstallation of the old application.

sorry for a very late reply VBScab, had to go on a forced vacation....
I rebuild the package to be sure that everything was okey.
It still is a mst over a msi installation.
This is how it looks so far (in both msi and mst):
version productcode packagecode upgradecode
Old version different different different same
New version different different different same

Now I dont get the msi error, the new package just installs together with the old package (both are showing in add/remove programs). Maybe I screwed something up with the msi/mst part? I point out the msi file as an upgrade in the upgrades propery (installation expert) but not the mst file right? But I have the same upgrade code both in msi and mst of the old package...should work shouldnt it?

Below ist the code setup for both old and new version
**********************************************************************************
OLD v1005
msi
---------------------
prodversion 12.0.6021.5000
prodcode {90120000-0020-041D-0000-0000000FF1CE}
packcode {45CC0A3D-01D5-4AED-96C5-38A8D303B275}
upgrcode {00120000-0020-0000-0000-0000000FF1CE}
mst
----------------------
prodversion 1.0.0.5
prodcode {2EEDC29B-F7AB-4AA8-90E8-24383E4235A6}
packcode {45CC0A3D-01D5-4AED-96C5-38A8D303B275}
upgrcode {00120000-0020-0000-0000-0000000FF1CE}

**********************************************************************************

**********************************************************************************
NEW v1006
------
msi
---------------------------
prodversion 12.0.6021.5000
prodcode {05401FE1-5CDF-4FDA-A405-771B05384BCA}
packcode {D6AD86E4-DECC-4C8D-A27C-D918F149CF03}
upgrcode {00120000-0020-0000-0000-0000000FF1CE}

mst
---------------------------
prodversion 1.0.0.6
prodcode {05401FE1-5CDF-4FDA-A405-771B05384BCA}
packcode {D6AD86E4-DECC-4C8D-A27C-D918F149CF03}
upgrcode {00120000-0020-0000-0000-0000000FF1CE}
**********************************************************************************

kindly,
Piotr

help please...anyone?

kindly,
Piotr

I think the reason why your set-up isn't working is that the Windows Installer engine only checks the first 3 parts of the version number. Thus, it regards 1.0.0.5 to be the same as 1.0.0.6. You would need to use 1.0.5 and 1.0.6 to trigger an upgrade.

However, why, on God's sweet Earth, are you replacing the ProductVersion?!? If you want to track your release of an official version, use a different property and write its value to the registry somewhere.

hmm...actually why we do it, I'm not sure... just a standard that "we are supposed to use". But the 1.0.0.X have never been an issue when upgrading other applications. Actually I did a dummy msi an a mst on it with 1.0.0.6 and the same codes as in the "real one" and it worked perfectly ie it uninstalled 1.0.0.5 and installed the 1.0.0.6, strange?