Learn how to a build a cloud-first strategyRegister Now

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 6563
  • Last Modified:

MSI (windows installer) installation using VSI (Visual Studio Installer) and Orca... Minor upgrade question...

First off, I could not find a channel dedicated to installation authoring, so I thought this channel would do!

Here is the scenario:

VB6 app:       app.exe
activex dll:     app.dll
3rd party dll:  dll.dll
3rd party ocx: ocx.ocx

I have created, in Visual Studio Installer 1.1, a .msi file for my app.  

I am deploying to 4 OS's:
WinXP
Win2K
Win98
WinNT 4.0

I have the installation package setup as such:
app.msi
Autorun.inf
InstMsiA.exe
InstMsiW.exe
setup.exe
setup.ini

For those not familiar:

-  The .msi is the package.
-  The Autorun.inf is for when I burn a CD, when that cd is put into the drive, it auto runs the setup.exe.  The contents of the Autorun.inf file is:
[autorun]
OPEN=setup.exe

-  The setup.ini contains:
[MSILoader]
MSIFileName=AEEDT.msi

-  The InstMsiA.exe and InstMsiW.exe files are for loading the Windows Installer on an OS (that doesn't already have it, usually Win98 and NT 4.0) in order to install the .msi package.

- If I had more time, I'd describe the steps involved in authoring the .msi in VSI, but that is a topic for another day...

Here is the issue:
The original installation works fine on all OS's.  No issues there (anymore!).  But, today's challenge is to code subsequent installations so that they will replace a previous installation of the same app.  So far, the only thing that has changed in the VB project is the .exe.

After much research, I've acquired a copy of Orca (an editor for .msi tables), added an Upgrade Table, and added to the Upgrade Table fields the following:

Upgrade Code:  {XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}  (I used the actual upgrade code from product information tab in the VSI project properties)
Version Min:  3.0.3.0
Version Max:  3.0.4.0
Language:  null
Attributes:  772
Remove:  null
ActionProperty:  FindRelatedProducts

The Attributes value of 722 is the sum of the following:
msidbUpgradeAttributesIgnoreRemoveFailure - 4  - Continue installation upon failure to remove a product or application.  
msidbUpgradeAttributesVersionMinInclusive - 256  - The range of versions detected includes the value in VersionMin.
msidbUpgradeAttributesVersionMaxInclusive - 512  - The range of versions detected includes the value in VersionMax.

In the original package, the (Product) version is 3.0.3.0, and in the second package it is 3.0.4.0.  Likewise with the two .exe's.
Before building the second .msi in VSI, I left the Upgrade Code the same, but changed the Product Code.

Now, when running both installs, the second does not prompt for upgrading the first, it just does a new install.  So, the first installation is not replaced, and there are two entries in Add/Remove programs.  

What I'd like to happen is that the second install (and subsequent installs) will prompt to remove or upgrade the previous.  Also, if the same exact installation package is run twice, the second running of the same package should detect and notify....

I think that maybe the Remove and/or ActionProperty is not set properly, or that I need more than one row in the Upgrade Table...

Thanks in advance for any help.  Please let me know if I need to provide further info or clarification.

Preece
0
Preece
Asked:
Preece
  • 2
  • 2
1 Solution
 
PreeceAuthor Commented:
Thanks, the second article, I think, is exactly what I'm looking for.  I've worked on it a bit, but will finish up on Monday!  Have a great weekend...

Preece
0
 
hesCommented:
Hope it works.
0
 
PreeceAuthor Commented:
Thanks Hes!  The second MS kb article worked great!
0

Featured Post

New feature and membership benefit!

New feature! Upgrade and increase expert visibility of your issues with Priority Questions.

  • 2
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now