Based on something Rob wrote at some point, I've been using * as Product Code
and not changing the upgrade code.
It really seems like the OP's basic requirement is that each release is an
independent product, so if they just do that they'll be 99% of the way there.
Of course the last 1% is
Silly naive question... Would giving each version a different Upgrade
codeand a version based destination directory (like MyApp.1.1.1 instead of
just MyApp) accomplish at least most of what Pavan wants?
On Mar 6, 2014 3:20 PM, Bryan Wolf brw...@jackhenry.com wrote:
My thoughts were more focused
Hi Walter,
Changing the upgrade code will only treat it as an upgrade. We would need to
change the product code to make it install side-by-side.
--Pavan
-Original Message-
From: Walter Dexter [mailto:wfdex...@gmail.com]
Sent: Friday, March 07, 2014 6:21 AM
To: General discussion for
I'm not recommending this, but technically it might be possible to
have one MSI file and a transform that turns it into a major upgrade.
Pre-install code could check the system and decide whether to install
the MSI raw as side by side or do an upgrade by applying the transform
at install time
Sorry accidentally sent too early;
But each release would be independent and you could e.g. push an uninstall
string and metadata in to the registry data or programdata (I recommend the
latter) and show that to the user with a nice UI so they could understand the
implications and you're no
This solution would also require a number of transforms dependent on the
permutations of releases. An n! number of target outputs quickly becomes
unmanageable is my point (i.e. at v5 you're looking at 120 build outputs and
test cases) :-)
I'm still convinced the first step is reducing the
Hi Jacob,
Thank you for your inputs. When you say Custom BA do you mean in the
bootstrapper?
The WIX upgrade functionality does the following am assuming automatically for
us:
--Uninstall the previous version(files and registry keys)
--Use the upgrading property to run our custom actions
Yes, CustomBA meaning custom bootstrapper. You would in fact be deploying
solely side by side installs with the BA knowing about all previous side by
side installs.
That being said, I would agree with John Coopers assessment of it not being a
good architecture. However you asked if it's
Hi John,
Thank you for your inputs.
Looks like things would get pretty complicated when Hotfixes and patches will
be involved.
The problem is the product architecture supports different versions residing
side-by-side. Been pulling my hair out to see how to make this work.
How about creating 2
Another way of looking at what John is suggesting is considering that you
probably want to take a step back a moment and focus more on version 3 and less
on version 2. You're looking at some sort of super-linear number of
installations you're going to have to support; all those permutations on
Hi Bryan,
Thank you for your inputs.
The product is installed for all users(per machine). All users have access to
any installed versions of the product on the machine. Am not sure if this will
make life easier!
The upgrade/side-by-side was being supported through Installanywhere
My thoughts were more focused on what the product actually supports in terms of
side-by-side and less of what MSI can do for you. Once you establish what the
product does, it'll be easier to model your installer better.
E.g. Visual Studio is basically sandboxed off but some features (like
Hi All,
Is it possible to create an installer that would do an upgrade or side-by-side
based on the user input?
Say we have 1.0 installed. When the user runs a version 2.0 of the same
product, give him a choice to either upgrade the existing or install as a side
by side.
Is it a good
Best I could think is to use Burn and make each install able to side by side
install, and conditionally remove the old copy based on user input inside a
custom BA.. You'd lose the major upgrade goodies of Windows Installer, but it
should work.
-Original Message-
From: Pavan Konduru
No (it's not a good architecture). Major Upgrade mostly works really well and
can be fully automated. Side-by-side converts it to a manual process. You're
also going to have to maintain a set of patches for each release (really, each
separate product, since you're going to have to have
15 matches
Mail list logo
