Minor upgrade does not work

  • Thread starter Marco Voorwinden
  • Start date
M

Marco Voorwinden

Hello all,

We've created quite a complex installer using InstallShield Developer 7 SP4,
and shipped version 2.1.1 to our customers. Now we're in the need of
applying a very minor 'patch' to our installation (resulting in the same
product version with only the build number changed). I tried this first
using the Tools/Generate Patch option, which did create a patch (.msp) file,
but that patch could not be installed (due to the MSDE merge module). Next I
tried it with a minor upgrade, but now it only installs part of the new
files. I've been working on this problem for a week now, and am quite
desperate

If anyone can help me with this, or encounters the same problem(s) please
reply to this post.

Thanks in advance!

Details:
The installation contains 3 features (Client,Server,Common), next to some
Merge Modules. Depending on the type of setup that is chosen
(Client,Server,Standalone) some features are selected for installation
(using the addlocal Event on the Next button of the dialog where the user
can select the type of installation).
Now for the upgrade (or patch) I compiled a new installer, where I changed
only the package code (according to the description in the Help).
Running this installation with the command line options REINSTALL=ALL and
REINSTALLMODE=vomus, does only install some of the new files, and not all.
(These files are all from the Common or the Server feature. nothing from
Client is installed)
Looking at the verbose logging, I found the following:
---snip---
MSI (s) (C4:40): Feature: Common; Installed: Local; Request: Reinstall;
Action: Reinstall
MSI (s) (C4:40): Feature: Client; Installed: Advertise; Request:
Reinstall; Action: Reinstall
---snip---

Strange that Common is installed as Local, and Client as Advertise!!!

This results in the fact that all the Client components are skipped:
---snip---
MSI (s) (C4:40): Component: Designer; Installed: Local; Request: Null;
Action: Null
MSI (s) (C4:40): Component: Images; Installed: Local; Request: Null;
Action: Null
---snip---

Can someone explain to me why it happens that one feature is installed as
Advertise and the other as Local?? As far as I can find in the MSI Project,
nothing is done to make the Client Feature advertise...
Can I change this during the upgrade maybe?

Thanks for any help.

Marco Voorwinden
 
M

Marco Voorwinden

Thanks Stefan for your answer. I checked the update rules at
http://www.installsite.org/pages/en/msi/updates.htm, but could not
find a rule that's being violated:
* Follow the rules for changing or keeping the ProductCode,
ProductVersion and UpgradeCode, depending of the type of update you
are creating. Always change the package code.
-> Changed the package code, for it is only a minor upgrade
* Do not move sub features. You can add new features and sub features.
-> did not move sub features
* Do not move componentes to other features.
-> did not move any components, only changed file (versions)
* If you are using the Windows Installer runtime version 1.x:
-> nope
* If you are using the Windows Installer runtime version 2.0 or above:
-> I do use version 2.0
* Do not change component codes.
-> Component codes not changed, some features contain components with
files added with wildcards, and I've seen someone mentioning that this
gives problems. Is that true??
* Do not change the name of the key file of a component.
-> Not changed
* You can modify the contents of a component (add, remove or modify
files, registry keys and shortcuts), but only if that component is not
shared across features.
-> I have the same files, with only newer versions
* If you remove a file or registry key from a component, you must
populate the RemoveFile or RemoveRegistry table respectively to delete
the orphaned resource.
-> Files are not removed
* Do not change the name of the .msi file.
-> Same name used

Next to this:
* I found some components without key file. Is that troublesome for
upgrading?
* Executing the installer for upgrading tells me that it's going into
maintenance mode. Is that correct?

Marco
 
S

Stefan Krueger [MVP]

* I found some components without key file. Is that troublesome for
upgrading?

In this case the directory will be the key. This shouldn't cause a problem
in general. However if the key path of a component isn't updated then none
of its contents will be updated.
* Executing the installer for upgrading tells me that it's going into
maintenance mode. Is that correct?

It should not showMaintenance mode is basically okay. It shouldn't ask you
whether you want to modify/repair/uninstall. Typically you would see the
"Resume" dialog instead of the "Welcome" dialog. What command line
parameters (REINSTALLMODE and REINSTALL) do you use to apply the minor
update?
-> Component codes not changed, some features contain components with
files added with wildcards, and I've seen someone mentioning that this
gives problems. Is that true??

In the Build wizard be sure to specify your old .msi file as Previous
Version in the Patch Optimization section. Do you include sub directories in
your dynamic links? At least in this case InstallShield automatically
assigns key files. Open your .msi file in Orca (or in Direct Edit mode in
InstallSheld) and chech the Key column in the Component table.

--
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)
 
M

Marco Voorwinden

Stefan Krueger said:
In this case the directory will be the key. This shouldn't cause a problem
in general. However if the key path of a component isn't updated then none
of its contents will be updated.


It should not showMaintenance mode is basically okay. It shouldn't ask you
whether you want to modify/repair/uninstall. Typically you would see the
"Resume" dialog instead of the "Welcome" dialog. What command line
parameters (REINSTALLMODE and REINSTALL) do you use to apply the minor
update?

I run it with REINSTALL=ALL and REINSTALLMODE=vomus. Indeed it comes
up with the resume dialog.
In the Build wizard be sure to specify your old .msi file as Previous
Version in the Patch Optimization section. Do you include sub directories in
your dynamic links? At least in this case InstallShield automatically
assigns key files. Open your .msi file in Orca (or in Direct Edit mode in
InstallSheld) and chech the Key column in the Component table.
I do use subdirs in some dynamic links, yes.
I specified the previous .msi as Previous Version, but that didn't
help either.
All the components that have dynamic links do NOT get a key file...
(Saw that in the .msi file, using Orca)

I'm still thinking the problem is caused by the Advertise installation
of the Client Feature... Some ideas about that?

After 'installing' the upgrade (which does not give errors) I try to
start the application and than it fires the installer again. Does this
help in understanding the problem?

Marco
 
M

Marco Voorwinden

Just some more info, next to the info I provided with my last post:
In my opinion the problem is being caused by the fact that the Client
feature is being installed as Advertise (somehow!??) So I tried to
repair this by doing the following:
I ran the original installation with
msiexec /fomus <productcode> ADDLOCAL=Client /L*v c:\repair.log

This logging tells me that the Client feature is installed Local
(hip,hip,hurah)

Next, I run the minor upgrade:
msiexec /I <msi package> ADDLOCAL=Client REINSTALL=Common,Server
REINSTALLMODE=vomus /L*v c:\upgrade.log

Now this logfile tells me again that the Client feature is installed
Advertise!! WHY??

I just don't get it anymore, maybe I'd better go for a major
upgrade...

Marco
 
S

Stefan Krueger [MVP]

That's what caught my eye from the beginning. If a feature that's installed
locally appears as advertised, you typically have moved a component, changed
a component GUID, or something like that. If you were using Developer 8 I'd
recommend to run the update validation, but that doesn't exist in version 7.
You could however get the eval. version, install it on a different computer,
load a copy (!) of your project, and perform the validation there.

--
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)
 
C

Carolyn Napier [MSFT]

One other thing to try:

Generate a transform between the original .MSI file and the new .MSI file.
The transform would then contain the differences which may shed some light
on what might have changed (particularly with respect to features and
components).

You can then use Orca to view the Transform in conjunction with the original
..MSI file. Orca will highlight the changed data based upon the information
in the transform file.

The Windows Installer SDK includes all of the tools you need to do view and
create transforms (Orca.msi, msitran.exe, wigenxfm.vbs, wilstxfm.vbs) .

Hope this helps,
- Carolyn Napier
Microsoft Windows Installer Team

--
This posting is provided "AS IS" with no warranties, and confers no rights.
Please do not send email directly to this alias. This alias is for newsgroup
purposes only.

MSI FAQ:
<http://www.microsoft.com/windows2000/community/centers/management/msi_faq.a
sp>
 
M

Marco Voorwinden

Sorry for the somewhat late response, but I was very buy doing other
things.

I did the thing you suggested, and Orca tells me indeed that some
components are changed. Looking deeper into it, these components are
components with dynamic file linking. This dynamic file linking
created apparently new guids for every build of the installer, so in
that case, a minor upgrade will never work...

Marco
 
S

Stefan Krueger [MVP]

Did you specify the old .msi file in the release wizard, under "Patch
Optimization"? This is required with dynamic file linking.

--
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)

Marco Voorwinden said:
Sorry for the somewhat late response, but I was very buy doing other
things.

I did the thing you suggested, and Orca tells me indeed that some
components are changed. Looking deeper into it, these components are
components with dynamic file linking. This dynamic file linking
created apparently new guids for every build of the installer, so in
that case, a minor upgrade will never work...

Marco

"Carolyn Napier [MSFT]" <[email protected]> wrote in message
One other thing to try:

Generate a transform between the original .MSI file and the new .MSI file.
The transform would then contain the differences which may shed some light
on what might have changed (particularly with respect to features and
components).

You can then use Orca to view the Transform in conjunction with the original
.MSI file. Orca will highlight the changed data based upon the information
in the transform file.

The Windows Installer SDK includes all of the tools you need to do view and
create transforms (Orca.msi, msitran.exe, wigenxfm.vbs, wilstxfm.vbs) .

Hope this helps,
- Carolyn Napier
Microsoft Windows Installer Team

--
This posting is provided "AS IS" with no warranties, and confers no rights.
Please do not send email directly to this alias. This alias is for newsgroup
purposes only.

MSI FAQ:
<http://www.microsoft.com/windows2000/community/centers/management/msi_faq.a
sp>


8
I'd version
7.

troublesome
for a
problem going
into shouldn't
ask
you see
the components
with that
this Edit
mode
in
 
M

Marco Voorwinden

At first I did not specify the old .msi file, but I tried that this
morning, and it still changes the component codes...

Stefan Krueger said:
Did you specify the old .msi file in the release wizard, under "Patch
Optimization"? This is required with dynamic file linking.

--
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)

Marco Voorwinden said:
Sorry for the somewhat late response, but I was very buy doing other
things.

I did the thing you suggested, and Orca tells me indeed that some
components are changed. Looking deeper into it, these components are
components with dynamic file linking. This dynamic file linking
created apparently new guids for every build of the installer, so in
that case, a minor upgrade will never work...

Marco

"Carolyn Napier [MSFT]" <[email protected]> wrote in message
One other thing to try:

Generate a transform between the original .MSI file and the new .MSI file.
The transform would then contain the differences which may shed some light
on what might have changed (particularly with respect to features and
components).

You can then use Orca to view the Transform in conjunction with the original
.MSI file. Orca will highlight the changed data based upon the information
in the transform file.

The Windows Installer SDK includes all of the tools you need to do view and
create transforms (Orca.msi, msitran.exe, wigenxfm.vbs, wilstxfm.vbs) .

Hope this helps,
- Carolyn Napier
Microsoft Windows Installer Team

--
This posting is provided "AS IS" with no warranties, and confers no rights.
Please do not send email directly to this alias. This alias is for newsgroup
purposes only.

MSI FAQ:
<http://www.microsoft.com/windows2000/community/centers/management/msi_faq.a
sp>


That's what caught my eye from the beginning. If a feature that's installed
locally appears as advertised, you typically have moved a component, changed
a component GUID, or something like that. If you were using Developer
8
I'd
recommend to run the update validation, but that doesn't exist in
version
7.
You could however get the eval. version, install it on a different computer,
load a copy (!) of your project, and perform the validation there.

--
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)


Just some more info, next to the info I provided with my last post:
In my opinion the problem is being caused by the fact that the Client
feature is being installed as Advertise (somehow!??) So I tried to
repair this by doing the following:
I ran the original installation with
msiexec /fomus <productcode> ADDLOCAL=Client /L*v c:\repair.log

This logging tells me that the Client feature is installed Local
(hip,hip,hurah)

Next, I run the minor upgrade:
msiexec /I <msi package> ADDLOCAL=Client REINSTALL=Common,Server
REINSTALLMODE=vomus /L*v c:\upgrade.log

Now this logfile tells me again that the Client feature is installed
Advertise!! WHY??

I just don't get it anymore, maybe I'd better go for a major
upgrade...

Marco

(e-mail address removed) (Marco Voorwinden) wrote in message
"Stefan Krueger [MVP]" <[email protected]> wrote in message
* I found some components without key file. Is that
troublesome
for
upgrading?

In this case the directory will be the key. This shouldn't cause
a
problem
in general. However if the key path of a component isn't updated
then
none
of its contents will be updated.

* Executing the installer for upgrading tells me that it's
going
into
maintenance mode. Is that correct?

It should not showMaintenance mode is basically okay. It shouldn't
ask
you
whether you want to modify/repair/uninstall. Typically you would
see
the
"Resume" dialog instead of the "Welcome" dialog. What command line
parameters (REINSTALLMODE and REINSTALL) do you use to apply the minor
update?

I run it with REINSTALL=ALL and REINSTALLMODE=vomus. Indeed it comes
up with the resume dialog.

-> Component codes not changed, some features contain
components
with
files added with wildcards, and I've seen someone mentioning
that
this
gives problems. Is that true??

In the Build wizard be sure to specify your old .msi file as Previous
Version in the Patch Optimization section. Do you include sub directories in
your dynamic links? At least in this case InstallShield automatically
assigns key files. Open your .msi file in Orca (or in Direct Edit
mode
in
InstallSheld) and chech the Key column in the Component table.

I do use subdirs in some dynamic links, yes.
I specified the previous .msi as Previous Version, but that didn't
help either.
All the components that have dynamic links do NOT get a key file...
(Saw that in the .msi file, using Orca)

I'm still thinking the problem is caused by the Advertise installation
of the Client Feature... Some ideas about that?

After 'installing' the upgrade (which does not give errors) I try to
start the application and than it fires the installer again. Does this
help in understanding the problem?

Marco
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top