Uninstalling

[GriffithsJ]

Hi

I'm trying to un-install a series of MSIs in a directory.

I use the following command line:

msiexec /x "myFile.msi" /qn

Almost all of the MSIs uninstall, except for a few. I don't know exactly
why this is, but I've got an idea and would like this confirmed.

There are two GUIDs for the MSI, one for Product Code and one for Upgrade
code. The guys that create these MSIs create a new code for both the
Product and the Upgrade code each time they release a new version of the
MSI. They have an application that checks whether it's using the "latest"
set of components and if not, uninstalls the existing one and re-installs
the updated version. Apparently, they need to change both or it doesn't
work.

Do they need to change both? If not, is it the Upgrade code they need to
change? Alternatively, is there another argument I can use for my
command-line?

Thanks

Griff

PS - sent this to two news-groups because I wasn't sure which was the most
appropriate one.

 

[Kallely Sajan]

Normally you don't change the UpgradeCode until the products transforms
itself into something else. More info on UpgradeCode is available at
http://msdn.microsoft.com/library/en-us/msi/setup/using_an_upgradecode.asp.
You change the ProductCode and not the UpgradeCode

Uninstall can also be launched by the command
msiexec /x {ProductCode}
--

Regards,
Sajan.

PS: Please don't send me direct emails, use the newsroom.

 

[GriffithsJ]

Thanks for the replies, however, if I may ask for clarification on a couple
of points...

1 - Say I've built an application in VB that has an executable and a series
of supporting DLLs. I've finished development on it and am ready to release
version 1 to the customers. I package the EXE and all supporting DLLs into
an MSI and assign it a ProductCode (let's call this GUID "PC1") and assign
it an UpgradeCode (let's call this GUID "UC1").

Two months down the line, I'm ready to release version 1.1 of the
application to the customer. I open the MSI and upgrade the DLLs that have
changed.

Solely from their names, I would have thought that I would have had to
change the Upgrade Code to "UC2", but left the ProductCode as "PC1".

Is this correct?

2) in terms of finding the product code, where would I find this?
Presumably in the registry?

Thanks for your help again!

Griff

When you point to an MSI file like that, what happens is that Windows looks at
the ProductCode in it and if that product isn't installed then nothing happens.
Kallely's answer is the right one - find the ProductCode Guid for the installed
product and use that in the /X command line.
--
Phil Wilson [MVP Windows Installer]
----

Hi

I'm trying to un-install a series of MSIs in a directory.

I use the following command line:

msiexec /x "myFile.msi" /qn

Almost all of the MSIs uninstall, except for a few. I don't know exactly
why this is, but I've got an idea and would like this confirmed.

There are two GUIDs for the MSI, one for Product Code and one for Upgrade
code. The guys that create these MSIs create a new code for both the
Product and the Upgrade code each time they release a new version of the
MSI. They have an application that checks whether it's using the "latest"
set of components and if not, uninstalls the existing one and re-installs
the updated version. Apparently, they need to change both or it doesn't
work.

Do they need to change both? If not, is it the Upgrade code they need to
change? Alternatively, is there another argument I can use for my
command-line?

Thanks

Griff

PS - sent this to two news-groups because I wasn't sure which was the most
appropriate one.

 

[Phil Wilson]

1) It's the upgradecode that must remain the same. Whether you change the
productcode or not depends on what kind of upgrade you want to do. If you want
to do a major upgrade you are required to change the productcode and version and
populate the upgrade table (how you do this depends on the tool). A minor update
means you change only the version, build the new msi and install with msiexec /i
<path to msi> REINSTALL=ALL REINSTALLMODE=vomus. The tool/IDE you use to develop
the MSI tends to be what determines which of these is easier.

2) This kind of code enumerates all the products on the system. It's VBScript,
but there are Win32 APIs too. This lists productcode guids and names installed
products.

Option Explicit
Public installer, fullmsg, comp, prod, a, fso, pname, ploc, pid, psorce

Set fso = CreateObject("Scripting.FileSystemObject")
Set a = fso.CreateTextFile("prods.txt", True)

' Connect to Windows Installer object
Set installer = CreateObject("WindowsInstaller.Installer")
a.writeline ("Products")
on error resume next
For Each prod In installer.products
pid = installer.productinfo (prod, "ProductID")
pname = installer.productinfo (prod, "InstalledProductName")
psorce=installer.productinfo(prod, "InstallSource")
ploc = installer.productinfo (prod, "InstallLocation")
a.writeline (prod & " " & pname & " " & ploc & " " & psorce)
Next

--
Phil Wilson [MVP Windows Installer]
----

Thanks for the replies, however, if I may ask for clarification on a couple
of points...

1 - Say I've built an application in VB that has an executable and a series
of supporting DLLs. I've finished development on it and am ready to release
version 1 to the customers. I package the EXE and all supporting DLLs into
an MSI and assign it a ProductCode (let's call this GUID "PC1") and assign
it an UpgradeCode (let's call this GUID "UC1").

Two months down the line, I'm ready to release version 1.1 of the
application to the customer. I open the MSI and upgrade the DLLs that have
changed.

Solely from their names, I would have thought that I would have had to
change the Upgrade Code to "UC2", but left the ProductCode as "PC1".

Is this correct?

2) in terms of finding the product code, where would I find this?
Presumably in the registry?

Thanks for your help again!

Griff

When you point to an MSI file like that, what happens is that Windows looks at
the ProductCode in it and if that product isn't installed then nothing happens.
Kallely's answer is the right one - find the ProductCode Guid for the installed
product and use that in the /X command line.
--
Phil Wilson [MVP Windows Installer]
----

Hi

I'm trying to un-install a series of MSIs in a directory.

I use the following command line:

msiexec /x "myFile.msi" /qn

Almost all of the MSIs uninstall, except for a few. I don't know exactly
why this is, but I've got an idea and would like this confirmed.

There are two GUIDs for the MSI, one for Product Code and one for Upgrade
code. The guys that create these MSIs create a new code for both the
Product and the Upgrade code each time they release a new version of the
MSI. They have an application that checks whether it's using the "latest"
set of components and if not, uninstalls the existing one and re-installs
the updated version. Apparently, they need to change both or it doesn't
work.

Do they need to change both? If not, is it the Upgrade code they need to
change? Alternatively, is there another argument I can use for my
command-line?

Thanks

Griff

PS - sent this to two news-groups because I wasn't sure which was the most
appropriate one.

 

[GriffithsJ]

Cracking! Thanks, that's really very useful.

Griff

 

[John]

Griff,

Here's how the codes work. There is actually 3 GUID's that
reference the package.

Productcode
Packagecode
Upgradecode

The product code is to the installer service the
identifiying feature of that package.

The package code is supposed to be used to versioning the
same package.

Ie lets say you built a package and made a mistake. You
then fix that package you should then increment the
package code. Its is kind of like a version for the same
version if that makes sense.

Now the upgrade code goes hand in hand with the upgrade
table. The idea of the upgrade code is to identify like
groups of packages.

Lets say in this example you have acrobat3 acrobat4 and
acrobat5 if you were to follow best practices all packages
would have the same upgrade code.

Now in reality this doesnt always happen, but heres what
you can do. The upgrade table simply looks for upgrade
codes that are already installed on the system.

In the acrobat example again say we installed acrobat 3
which was PC1 and UC1 as per your naming convention.

Then we install arcobat4 which would be PC2 technically
the upgrade code of acrobat4 should be the same but in
reality if it wasnt it makes no difference at all. The
item of importance is the upgrade table. The upgrade table
is searched for upgrade codes, if upgrade codes are found
in the upgrade table then the installer service is queried
to see if the upgrade codes exist on the local
workstation. If found action codes are set from the
upgrade table. Now dependant on the attribute setting of
the upgrade table depends on what action is performed.

The whole idea behind this is that if you released acrobat
3 then acrobat 4 that you could uninstall acrobat 3 during
the install of acrobat 4

All you need to know if you want this to happen is that
whatever packages you want uninstalled by your latest
verion simply needs the upgrade codes / version of all the
application you want to remove.

Ie install acrobat3 PC1 has UC1

then if you install acrobat4 PC2 you need to put UC1 into
the upgrade table of PC2. Then it will perform the
uninstall.

If you didnt have the same upgrade code in both package it
will still work. But you are supposed to have it.

hope this helps.

John