I don't believe what you want is achievable with windows installer, but
I'm not an expert...
I think what you could do is make each "version" a "feature" in windows
installer terminology, and require installations to always be done via the
most recent install package.
You could then use 'major' upgrades to ensure that the previous 'package'
gets uninstalled and use the major upgrade ability to "tell" you what
features were installed in the previous package and make those the
features that are automatically selected when starting the 'new' package.
Not sure if this solves your problem or not. Here's how I thought it
would work:
ver1.0 == "VER10" feature
ver1.1 == "VER11" feature
ver2.0 == "VER20" feature
ver2.1 == "VER21" feature.
packages:
when ver1.1 released, the package (package 1) contains VER10 and VER11
features. VER11 is selected by default, but the user can select VER10 as
well (or maybe everything is selected by default).
when ver2.0 released, the package (package 2) contains VER10, VER11, and
VER20 features. similarly, all are selected by default (on a "new"
install).
if a user tries to install package1 on a machine that already has
package2, they'll be told they need to get the most recent version of the
installer package because a newer version is already installed. If a user
tries to install package2 on a machine that already has package1, package2
will perform a major upgrade, removing the package1 and installing the
same features as package1 plus the ver20 feature (which should always be
installed when running the package2 - I think???)
Anyway, hopefully that's enough detail for you to try it out.
"Bryan C. Boettcher" <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED]
11/29/2007 09:55 AM
To
"wix-users@lists.sourceforge.net" <wix-users@lists.sourceforge.net>
cc
Subject
[WiX-users] Concurrent versions?
We have a somewhat unique requirement for our product. Concurrent
versions need to be made available on a single machine. We have a matched
client and server, for which the protocol changes each version. One
desktop machine might need to talk to 5 differently-versioned servers, and
will need 5 versions of the components.
A server hosts a website with a link to the installation package, so
obtaining the server-specific version isn't an issue, so I don't know if a
patch will work. What is an issue is that the versions might be installed
in any order. The server's website will then use object tags with
hardcoded CLSIDs to launch the version-specific components. This
currently works with Internet Component Download, since it creates the
CONFLICT.# directories.
All versions need to have a few common files in %system32%. These files
might get upgraded in a future release, but will retain their binary
compatibility.
All versions of the product need to show up as one Add/Remove programs
entry, and this is the tricky part for me. Removal of that one program
needs to remove all versions currently installed, and all registry that's
been affected by several overlapping COM components. If it wasn't for
this requirement I would happily create a different product UUID each
time, since that's essentially the behavior we want anyway.
Anybody have suggestions on how to proceed?
Thanks,
-Bryan
-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell. From the desktop to the data center, Linux is going
mainstream. Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
_______________________________________________
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
**************************************************************************************
This communication is intended solely for the addressee and is
confidential. If you are not the intended recipient, any disclosure,
copying, distribution or any action taken or omitted to be taken in
reliance on it, is prohibited and may be unlawful. Unless indicated
to the contrary: it does not constitute professional advice or
opinions upon which reliance may be made by the addressee or any
other party, and it should be considered to be a work in progress.
Unless stated otherwise, this communication does not form a prescribed
statement of actuarial opinion under American Academy of Actuaries
guidelines.
**************************************************************************************
-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell. From the desktop to the data center, Linux is going
mainstream. Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
_______________________________________________
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
