Hi all,

If I generate with InstallShield 2 different Product Configurations, one
for instance everything packed in setup.exe and one for instance the
uncompressed package, and I install using one of those and then run the
other one I get the error "Another version of this product is already
installed. Installation of this version cannot continue. To configure or
remove the existing version of this product, use Add/Remove Programs on
the Control Panel.".

I searched to find out why and I found: "This normally happens when
another setup on the system was installed with the same Product Code,
but with a different Package Code.". This surprises me because actually
as far as I understood actually every new build of your product should
have different Package Code. I mean when I change something in my
project and I build the project as far as I read into the docu the
Package Code changes but the Product Code stays the same and when I run
it I get: "This setup will perform an upgrade of 'producut'. Do you want
to continue?"

Q1: I really don't understand why I get this different behaviour. Can
pls somebody explain?
Q2: Can somebody tell me with Orca where should I look to see the
Package Code?

Thank you,
Viv

Viviana Vc wrote:
> Hi all,
>
> If I generate with InstallShield 2 different Product Configurations, one
> for instance everything packed in setup.exe and one for instance the
> uncompressed package, and I install using one of those and then run the
> other one I get the error "Another version of this product is already
> installed. Installation of this version cannot continue. To configure or
> remove the existing version of this product, use Add/Remove Programs on
> the Control Panel.".
>
> I searched to find out why and I found: "This normally happens when
> another setup on the system was installed with the same Product Code,
> but with a different Package Code.".
There's a bit missing from this. It happens if a product is already is installed with a different
package code but with the same Product Code *and the same Product Version*.


This surprises me because actually
> as far as I understood actually every new build of your product should
> have different Package Code. I mean when I change something in my
> project and I build the project as far as I read into the docu the
> Package Code changes but the Product Code stays the same and when I run
> it I get: "This setup will perform an upgrade of 'producut'. Do you want
> to continue?"
>
> Q1: I really don't understand why I get this different behaviour. Can
> pls somebody explain?
See above
> Q2: Can somebody tell me with Orca where should I look to see the
> Package Code?
View -> Summary Information...


Rob

>
> Thank you,
> Viv

Just to add to the other comment, InstallShield is one of those tools that
doesn't change Guids automatically. There's an assumption that that setup
developer will change those things if needed.

Also, you won't get an upgrade unless the UpgradeTable is populated to do a
major upgrade (which requires different ProductCode Guid, among other
things).
--
Phil Wilson [MVP Windows Installer]
----
"Viviana Vc" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Hi all,
>
> If I generate with InstallShield 2 different Product Configurations, one
> for instance everything packed in setup.exe and one for instance the
> uncompressed package, and I install using one of those and then run the
> other one I get the error "Another version of this product is already
> installed. Installation of this version cannot continue. To configure or
> remove the existing version of this product, use Add/Remove Programs on
> the Control Panel.".
>
> I searched to find out why and I found: "This normally happens when
> another setup on the system was installed with the same Product Code,
> but with a different Package Code.". This surprises me because actually
> as far as I understood actually every new build of your product should
> have different Package Code. I mean when I change something in my
> project and I build the project as far as I read into the docu the
> Package Code changes but the Product Code stays the same and when I run
> it I get: "This setup will perform an upgrade of 'producut'. Do you want
> to continue?"
>
> Q1: I really don't understand why I get this different behaviour. Can
> pls somebody explain?
> Q2: Can somebody tell me with Orca where should I look to see the
> Package Code?
>
> Thank you,
> Viv

Hi,

Thank you both for your answers.

I checked with Orca the ProductVersion but it's the same for all my
built products: 1.00.0000
I checked also the PackageCode and it's different for each build (I
didn't manually change it, so must have been IS taking care of this).

But maybe in order to help me you need more info. Here is what I have
tried:

1) MSI behaviour (I created an uncompressed network-image package)
a) Run first time the MSI => product gets installed.
b) Running the same MSI => maintenance dialog, which is normal
c) Runing a new built MSI file (everything stayed the same, I just
rebuilt the package again) => I get the "Another version [...]"

2) Setup.exe behaviour (I created a compressed network-image package)
a) Run first time the setup.exe => product gets installed.
b) Running the same setup.exe => maintenance dialog, which is normal
c) Runing a new built setup.exe file (everything stayed the same, I just
rebuilt the package again) => I get the "This setup will perform an
upgrade of 'tmp'. Do you want to continue?"

Why do I have this different behaviour between 1c and 2c? It's obviously
that scenario 1) is the one I would expect after your explanations, but
then why the different behaviour in scenario 2? Also I uncompressed the
two setup.exe I built, using /v /a and checked the MSI files and they
both having the exact same version. By running the extracted MSI file I
get "Another version [...]"; by running the setup.exe from which I just
extracted the MSI I get "This setup will perform an upgrade of 'tmp'."


3) I run the MSI to install the product and then run the setup.exe. Both
were built from the exact same sources, just 2 release configurations. I
get: "This setup will perform an upgrade of 'tmp'. Do you want to
continue?"

4) I run the setup.exe to install the product and then run the MSI. Both
were built from the exact same sources, just 2 release configurations. I
get: "Another version [...]"

Why the different behaviour between 3 and 4?

From all the above experiences it's obviously that:
- the version is not changed
- the PackageCode is changed
- the Product Code is the same
- the MSI behaves as expected ("Another version [...]")
- the setup.exe behaves like the version was changed (like a minor
update: "This setup will perform an upgrade of 'tmp'")

Why is that?

Sorry for te long post and thx,
Viv

On Thu, 8 Dec 2005 14:25:51 -0800, "Phil Wilson"
<(E-Mail Removed)> wrote :

>Just to add to the other comment, InstallShield is one of those tools that
>doesn't change Guids automatically. There's an assumption that that setup
>developer will change those things if needed.
>
>Also, you won't get an upgrade unless the UpgradeTable is populated to do a
>major upgrade (which requires different ProductCode Guid, among other
>things).

And actually just now I tried the following: 2 MSI files generated from
the same project with:
- same Product Code
- different Package Code
- diferrent version (previous was 2.10.0000, new is 2.11.0001)
and I still get the "Another version [...]" messagebox.
Any clue why? What am I doing wrong?

Thank you,
Viv

On Fri, 09 Dec 2005 15:27:55 +0100, Viviana Vc <(E-Mail Removed)>
wrote :

>Hi,
>
>Thank you both for your answers.
>
>I checked with Orca the ProductVersion but it's the same for all my
>built products: 1.00.0000
>I checked also the PackageCode and it's different for each build (I
>didn't manually change it, so must have been IS taking care of this).
>
>But maybe in order to help me you need more info. Here is what I have
>tried:
>
>1) MSI behaviour (I created an uncompressed network-image package)
>a) Run first time the MSI => product gets installed.
>b) Running the same MSI => maintenance dialog, which is normal
>c) Runing a new built MSI file (everything stayed the same, I just
>rebuilt the package again) => I get the "Another version [...]"
>
>2) Setup.exe behaviour (I created a compressed network-image package)
>a) Run first time the setup.exe => product gets installed.
>b) Running the same setup.exe => maintenance dialog, which is normal
>c) Runing a new built setup.exe file (everything stayed the same, I just
>rebuilt the package again) => I get the "This setup will perform an
>upgrade of 'tmp'. Do you want to continue?"
>
>Why do I have this different behaviour between 1c and 2c? It's obviously
>that scenario 1) is the one I would expect after your explanations, but
>then why the different behaviour in scenario 2? Also I uncompressed the
>two setup.exe I built, using /v /a and checked the MSI files and they
>both having the exact same version. By running the extracted MSI file I
>get "Another version [...]"; by running the setup.exe from which I just
>extracted the MSI I get "This setup will perform an upgrade of 'tmp'."
>
>
>3) I run the MSI to install the product and then run the setup.exe. Both
>were built from the exact same sources, just 2 release configurations. I
>get: "This setup will perform an upgrade of 'tmp'. Do you want to
>continue?"
>
>4) I run the setup.exe to install the product and then run the MSI. Both
>were built from the exact same sources, just 2 release configurations. I
>get: "Another version [...]"
>
>Why the different behaviour between 3 and 4?
>
>From all the above experiences it's obviously that:
>- the version is not changed
>- the PackageCode is changed
>- the Product Code is the same
>- the MSI behaves as expected ("Another version [...]")
>- the setup.exe behaves like the version was changed (like a minor
>update: "This setup will perform an upgrade of 'tmp'")
>
>Why is that?
>
>Sorry for te long post and thx,
>Viv
>
>On Thu, 8 Dec 2005 14:25:51 -0800, "Phil Wilson"
><(E-Mail Removed)> wrote :
>
>>Just to add to the other comment, InstallShield is one of those tools that
>>doesn't change Guids automatically. There's an assumption that that setup
>>developer will change those things if needed.
>>
>>Also, you won't get an upgrade unless the UpgradeTable is populated to do a
>>major upgrade (which requires different ProductCode Guid, among other
>>things).

"Phil Wilson" <(E-Mail Removed)> schrieb im Newsbeitrag
news:OE4pZZE$(E-Mail Removed)...
> Just to add to the other comment, InstallShield is one of those tools that
> doesn't change Guids automatically. There's an assumption that that setup
> developer will change those things if needed.

In recent versons of InstallShield there's an option to automatiucally
generate a new PackageCode with each build, and it's turned on by default.

> Also, you won't get an upgrade unless the UpgradeTable is populated to do
> a major upgrade (which requires different ProductCode Guid, among other
> things).

You can do Small and Minor Updates wihtout UpgradeTable entries.
InstallShield's setup.exe automatically sets REINSTALLMODE=vomus if it
detects an older version of the same ProductCode on the machine.

--
Stefan Krueger
Microsoft Windows Installer MVP

Please post your questions in the newsgroup or vist one of these web sites:

Windows Installer FAQ
http://www.msifaq.com - http://www.msifaq.de

InstallSite - Resources for Setup Developers
http://www.installsite.org
http://www.installsite.de (GERMAN)

What you are seein is by design. When you build to packages with different
PackageCodes then you actually have to different "versions" (maybe the
message should more accurately say "releases") of the same product, even if
the "version number" is identical.

What are you trying to do? If you wantr to install the second release on top
of the first then this would actually be a small (if the version number is
the unchanged) or minor (if yo incremented the version number) update. There
is documentation about this in the SDK, basically you would have to set
REINSTALLMODE=vomus REINSTALL=ALL on the command line when installing the
second package. InstallShield's setup.exe can do this for you automatically
(unless you disabled this in the release settings). You have to do it
manually if you start the .msi file directly without setup.exe.

--
Stefan Krueger
Microsoft Windows Installer MVP

Please post your questions in the newsgroup or vist one of these web sites:

Windows Installer FAQ
http://www.msifaq.com - http://www.msifaq.de

InstallSite - Resources for Setup Developers
http://www.installsite.org
http://www.installsite.de (GERMAN)

"Viviana Vc" <(E-Mail Removed)> schrieb im Newsbeitrag
news:(E-Mail Removed)...
> And actually just now I tried the following: 2 MSI files generated from
> the same project with:
> - same Product Code
> - different Package Code
> - diferrent version (previous was 2.10.0000, new is 2.11.0001)
> and I still get the "Another version [...]" messagebox.
> Any clue why? What am I doing wrong?
>
> Thank you,
> Viv
>
> On Fri, 09 Dec 2005 15:27:55 +0100, Viviana Vc <(E-Mail Removed)>
> wrote :
>
>>Hi,
>>
>>Thank you both for your answers.
>>
>>I checked with Orca the ProductVersion but it's the same for all my
>>built products: 1.00.0000
>>I checked also the PackageCode and it's different for each build (I
>>didn't manually change it, so must have been IS taking care of this).
>>
>>But maybe in order to help me you need more info. Here is what I have
>>tried:
>>
>>1) MSI behaviour (I created an uncompressed network-image package)
>>a) Run first time the MSI => product gets installed.
>>b) Running the same MSI => maintenance dialog, which is normal
>>c) Runing a new built MSI file (everything stayed the same, I just
>>rebuilt the package again) => I get the "Another version [...]"
>>
>>2) Setup.exe behaviour (I created a compressed network-image package)
>>a) Run first time the setup.exe => product gets installed.
>>b) Running the same setup.exe => maintenance dialog, which is normal
>>c) Runing a new built setup.exe file (everything stayed the same, I just
>>rebuilt the package again) => I get the "This setup will perform an
>>upgrade of 'tmp'. Do you want to continue?"
>>
>>Why do I have this different behaviour between 1c and 2c? It's obviously
>>that scenario 1) is the one I would expect after your explanations, but
>>then why the different behaviour in scenario 2? Also I uncompressed the
>>two setup.exe I built, using /v /a and checked the MSI files and they
>>both having the exact same version. By running the extracted MSI file I
>>get "Another version [...]"; by running the setup.exe from which I just
>>extracted the MSI I get "This setup will perform an upgrade of 'tmp'."
>>
>>
>>3) I run the MSI to install the product and then run the setup.exe. Both
>>were built from the exact same sources, just 2 release configurations. I
>>get: "This setup will perform an upgrade of 'tmp'. Do you want to
>>continue?"
>>
>>4) I run the setup.exe to install the product and then run the MSI. Both
>>were built from the exact same sources, just 2 release configurations. I
>>get: "Another version [...]"
>>
>>Why the different behaviour between 3 and 4?
>>
>>From all the above experiences it's obviously that:
>>- the version is not changed
>>- the PackageCode is changed
>>- the Product Code is the same
>>- the MSI behaves as expected ("Another version [...]")
>>- the setup.exe behaves like the version was changed (like a minor
>>update: "This setup will perform an upgrade of 'tmp'")
>>
>>Why is that?
>>
>>Sorry for te long post and thx,
>>Viv
>>
>>On Thu, 8 Dec 2005 14:25:51 -0800, "Phil Wilson"
>><(E-Mail Removed)> wrote :
>>
>>>Just to add to the other comment, InstallShield is one of those tools
>>>that
>>>doesn't change Guids automatically. There's an assumption that that setup
>>>developer will change those things if needed.
>>>
>>>Also, you won't get an upgrade unless the UpgradeTable is populated to do
>>>a
>>>major upgrade (which requires different ProductCode Guid, among other
>>>things).
>

Hi Stefan,

Thanks for your answer.

Just to be sure I understood correctly:
a) the difference between small and minor updates are that for small
update the version doesn't change at all and for minor update the
version changes (from aaa.bbb.cccc to aaa.bbb+x.cccc, where x can be any
positive number) correct?
b) REINSTALLMODE=vomus REINSTALL=ALL is doing the trick and the IS's
setup.exe already does this: runs the msi with this params? Any clue
where to check this in IS to see these command lines params? (I see in
Property Manager a "ReinstallModeText" set on omus, but I can't see the
REINSTALLMODE or REINSTALL)
c) for a msi to really do an update (regardless of what kind of update:
small, minor, major) it's always needed to manually give the
REINSTALLMODE=vomus REINSTALL=ALL parameters in the line command
correct? There is no way to by default have those params set?
d) so I get the "Another version of this product is already installed
[...]" whenever I just duble-click a msi for a product that is already
installed on the system with a different PackageCode, correct? Meaning:
same ProdctCode, different PackageCode, and the other settings don't
really matter, correct?

Thank you,
Viv


On Sat, 10 Dec 2005 11:19:02 +0100, "Stefan Krueger [MVP]"
<(E-Mail Removed)> wrote :

>What you are seein is by design. When you build to packages with different
>PackageCodes then you actually have to different "versions" (maybe the
>message should more accurately say "releases") of the same product, even if
>the "version number" is identical.
>
>What are you trying to do? If you wantr to install the second release on top
>of the first then this would actually be a small (if the version number is
>the unchanged) or minor (if yo incremented the version number) update. There
>is documentation about this in the SDK, basically you would have to set
>REINSTALLMODE=vomus REINSTALL=ALL on the command line when installing the
>second package. InstallShield's setup.exe can do this for you automatically
>(unless you disabled this in the release settings). You have to do it
>manually if you start the .msi file directly without setup.exe.

Stefan, that's interesting. Viviana has had other questions about this kind
of thing where InstallShield is doing something extra that MSI isn't doing.
It's tough to sort out whether these should be questions in an InstallShield
forum or in an MSI forum.
--
Phil Wilson [MVP Windows Installer]
----
"Stefan Krueger [MVP]" <(E-Mail Removed)> wrote in message
news:%23uF4eOX$(E-Mail Removed)...
> "Phil Wilson" <(E-Mail Removed)> schrieb im Newsbeitrag
> news:OE4pZZE$(E-Mail Removed)...
>> Just to add to the other comment, InstallShield is one of those tools
>> that doesn't change Guids automatically. There's an assumption that that
>> setup developer will change those things if needed.
>
> In recent versons of InstallShield there's an option to automatiucally
> generate a new PackageCode with each build, and it's turned on by default.
>
>> Also, you won't get an upgrade unless the UpgradeTable is populated to do
>> a major upgrade (which requires different ProductCode Guid, among other
>> things).
>
> You can do Small and Minor Updates wihtout UpgradeTable entries.
> InstallShield's setup.exe automatically sets REINSTALLMODE=vomus if it
> detects an older version of the same ProductCode on the machine.
>
> --
> Stefan Krueger
> Microsoft Windows Installer MVP
>
> Please post your questions in the newsgroup or vist one of these web
> sites:
>
> Windows Installer FAQ
> http://www.msifaq.com - http://www.msifaq.de
>
> InstallSite - Resources for Setup Developers
> http://www.installsite.org
> http://www.installsite.de (GERMAN)
>

Well, sometimes I am not even sure if something is a MSI or a
InstallShiled "feature". In both areas I am pretty new and both things
are pretty complex.
Also I have some experience with Install Script and while working with
that I noticed that their forum (at least the one related with
InstallScript) was pretty dead

Nevertheless, thanks to all of you that are helping me and sorry if I
ask beginners questions,
Viv

On Mon, 12 Dec 2005 11:49:15 -0800, "Phil Wilson"
<(E-Mail Removed)> wrote :

>Stefan, that's interesting. Viviana has had other questions about this kind
>of thing where InstallShield is doing something extra that MSI isn't doing.
>It's tough to sort out whether these should be questions in an InstallShield
>forum or in an MSI forum.