://www.firegiant.com/
-Original Message-
From: Lukas Rieger [mailto:lrie...@nemetschek-engineering.at]
Sent: Friday, April 24, 2015 11:33 AM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] Major upgrade: a few files are not installed
I thought it treated files like MSIs
ng
An: "General discussion about the WiX toolset."
Datum: 24.04.2015 20:13
Betreff: Re: [WiX-users] Major upgrade: a few files are not
installed
Windows Installer only ignores the 4th digit of the MSI version. It'll
evaluate all four pla
Lukas Rieger [mailto:lrie...@nemetschek-engineering.at]
Sent: Friday, April 24, 2015 10:59 AM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] Major upgrade: a few files are not installed
I opened up both MSIs in Orca and compared their version numbers.
The missing files are diff
up and thank you,
Lukas
Von:Rob Mensching
An: "General discussion about the WiX toolset."
Datum: 14.04.2015 02:49
Betreff: Re: [WiX-users] Major upgrade: a few files are not
installed
You should root cause why higher version Components exist on the machine
:lrie...@nemetschek-engineering.at]
> Sent: Monday, April 13, 2015 2:29 PM
> To: wix-users@lists.sourceforge.net
> Subject: Re: [WiX-users] Major upgrade: a few files are not installed
>
> Sorry, I forgot to mention that I am using Burn as Bootstrapper, so I can'
[mailto:lrie...@nemetschek-engineering.at]
Sent: Monday, April 13, 2015 2:29 PM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Major upgrade: a few files are not installed
Sorry, I forgot to mention that I am using Burn as Bootstrapper, so I can't
control the REINSTALLMODE
Than
Sorry, I forgot to mention that I am using Burn as Bootstrapper, so I
can't control the REINSTALLMODE
Thank you,
Lukas
Von:Joel Budreau
An: lrie...@nemetschek-engineering.at
Kopie: "General discussion about the WiX toolset."
Datum: 13.04.2015 23:21
Betreff:
You could pass REINSTALLMODE=amus so that all files are overwritten by the
newer MSI - https://msdn.microsoft.com/en-us/library/aa371182%28v=vs.85%29.aspx
> On Apr 13, 2015, at 9:36 AM, Lukas Rieger
> wrote:
>
> I have the same issue as described here:
> http://stackoverflow.com/questions/151
t;
> -Message d'origine-
> De : Hoover, Jacob [mailto:jacob.hoo...@greenheck.com]
> Envoyé : jeudi 6 novembre 2014 15:53
> À : General discussion about the WiX toolset.
> Cc : FAURE Helian
> Objet : Re: [WiX-users] Major Upgrade : Conditional uninstallation on even
&g
Thanks for your answer Jacob.
I ended on same conclusion about the custom BA.
-Message d'origine-
De : Hoover, Jacob [mailto:jacob.hoo...@greenheck.com]
Envoyé : jeudi 6 novembre 2014 15:53
À : General discussion about the WiX toolset.
Cc : FAURE Helian
Objet : Re: [WiX-users]
I've got a similar requirement. In order to only conditionally uninstall, each
"major upgrade" needs to have a new upgrade code and product code. In my use
case the application will only be installed by a bundle, so I can add a related
bundle with an action of detect and conditionally request t
Hi Phil,
For patches i use the related bundle action as patch and leave the GUID the
same, this is how its removing the patches when removing the main bundle.
When installaing a major upgrade (a new major release) the related bundle
guid changes and the action goes back to detect. i leave the upg
Did you see this thread?
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Re-Burn-patch-for-bundle-td7291580.html
Some time ago I did an experiment along this line. I think I used 'add-in'
or 'update' but not 'patch'. And I added code to my mba. For me the
updated bundle was remove
Thanks Phil,
i moved the post to wix users.
i set the upgrade code for the major upgrade(New Bundle) to be the same as
the upgrade code in the RTM(Old Bundle). Now it removes the entry of the Old
Bundle from the ARP (also from the registry) but the patch is not removed
from the "installed updates
de [mailto:kirann.he...@gmail.com]
> Sent: Tuesday, April 22, 2014 10:41 PM
> To: wix-users@lists.sourceforge.net
> Subject: Re: [WiX-users] Major upgrade removing files
>
> Folks,
>
> Thanks for all the responses.
>
> This issue happens even with normal files(not j
-users@lists.sourceforge.net
Subject: Re: [WiX-users] Major upgrade removing files
Folks,
Thanks for all the responses.
This issue happens even with normal files(not just assemblies)
MSI (s) (48:F0) [07:39:21:024]: Disallowing installation of component:
{4D2EB851-13AC-500F-9704-AB78102F8D0F} since
Dit mailadres is niet meer in gebruik. Mail kan je voortaan sturen naar
basti...@careercontrol.nl.
--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Jav
Folks,
Thanks for all the responses.
This issue happens even with normal files(not just assemblies)
MSI (s) (48:F0) [07:39:21:024]: Disallowing installation of component:
{4D2EB851-13AC-500F-9704-AB78102F8D0F} since the same component with higher
versioned keyfile exists
I dont want to implemen
on you're not really supposed to just yank things out of the
> GAC or Win32 assembly stores.
>
> -Original Message-
> From: Carter Young [mailto:ecyo...@grandecom.net]
> Sent: Tuesday, April 22, 2014 2:54 PM
> To: wix-users@lists.sourceforge.net
> Subject: Re:
-
From: Carter Young [mailto:ecyo...@grandecom.net]
Sent: Tuesday, April 22, 2014 2:54 PM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Major upgrade removing files
Dobt all Assemblies get added to the GAC though?? Then use the Version Search
to Search the GAC. Could be totally wr
good" answer for assemblies. As a warning:
>> sequencing REP before CostInitialize does cause an ICE27 error.
>>
>> -----Original Message-
>> From: Phil Wilson [mailto:phildgwil...@gmail.com]
>> Sent: Tuesday, April 22, 2014 11:04 AM
>> To: General discussi
014 2:18 PM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Major upgrade removing files
I may be talking out the side of my mouth here,, but why cant he remove version
N doing a version check like so:
http://wixtoolset.org/documentation/manual/v3/howtos/files_and_registry/check_the_version_num
From: Phil Wilson [mailto:phildgwil...@gmail.com]
> Sent: Tuesday, April 22, 2014 11:04 AM
> To: General discussion about the WiX toolset.
> Subject: Re: [WiX-users] Major upgrade removing files
>
> This shouldn't apply to later MSI engines - according this KB
> article it sho
11:04 AM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] Major upgrade removing files
This shouldn't apply to later MSI engines - according this KB article it
shouldn't be a problem if you make sure you have at least MSI 4.0, or ship the
4.5 redist.
http://support.micros
Dit mailadres is niet meer in gebruik. Mail kan je voortaan sturen naar
basti...@careercontrol.nl.
--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Jav
This shouldn't apply to later MSI engines - according this KB article
it shouldn't be a problem if you make sure you have at least MSI 4.0,
or ship the 4.5 redist.
http://support.microsoft.com/kb/905238/en-us
but I vaguely remember the original MSI needs installing with a
correct MSI engine too,
The always overwrite flag in InstallShield just sets the FileVersion column to
65535.0.0.0. WiX has the DefaultVersion field, which should duplicate the
experience. Alternatively, just modify the MSI post-build for this one-off. It
would be easier if you were not using an assembly file because y
Mensching [mailto:r...@robmensching.com]
Sent: Thursday, September 05, 2013 11:01 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Major Upgrade Schedule Not Working?
You can upgrade the old MSI via your new MSI in the new Bundle so the old
Bundle uninstall doesn&
toolset.
Subject: Re: [WiX-users] Major Upgrade Schedule Not Working?
Hi all,
Please stop including me in the discussion.
Thanks,
Best regards,
Marie Gourmelon
Talent Source Staffing Specialist | Allegis Group Services
Mobile:
Office:
+33 6 76 92 98 74
+33 1 57 75 34 91
TSPO:
+33 1 57
>
>
> -Original Message-
> From: Rob Mensching [mailto:r...@robmensching.com]
> Sent: Thursday, September 05, 2013 10:19 AM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Major Upgrade Schedule Not Working?
>
> The Burn executi
hange this
behavior.
-Original Message-
From: Rob Mensching [mailto:r...@robmensching.com]
Sent: Thursday, September 05, 2013 10:19 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Major Upgrade Schedule Not Working?
The Burn execution order is
igine-
De : Andrew Meyer [mailto:ame...@creativestrategiesus.com]
Envoyé : jeudi 5 septembre 2013 16:47
À : 'General discussion for Windows Installer XML toolset.'
Objet : Re: [WiX-users] Major Upgrade Schedule Not Working?
It seems this is by design, to Install then Uninstall. Any
w bundle then uninstalling the old
> afterwards. I can't find any documentation in Burn to change this behavior
> otherwise.
>
>
> -Original Message-
> From: Bob Arnson [mailto:b...@joyofsetup.com]
> Sent: Wednesday, September 04, 2013 5:23 PM
> To: wix-users
in Burn to change this behavior
otherwise.
-Original Message-
From: Bob Arnson [mailto:b...@joyofsetup.com]
Sent: Wednesday, September 04, 2013 5:23 PM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Major Upgrade Schedule Not Working?
On 04-Sep-13 15:13, Andrew Meyer wrote:
&
On 04-Sep-13 15:13, Andrew Meyer wrote:
> No matter how I define "Schedule" in the MajorUpgrade node, during a Major
> update, the installer always acts like Schedule is set to
> afterInstallExecute.
Use the Orca tool to verify whether RemoveExistingProducts is actually
scheduled.
--
sig://boB
h
ion No. 4452522,
with registered offices at 67 Innovation Drive, Milton Park, Abingdon,
Oxfordshire. OX14 4RQ. UK. VAT No. 821339546.
-Original Message-
From: Dave Moss [mailto:davidm...@omprompt.com]
Sent: 24 May 2013 09:12
To: Hoover, Jacob
Cc: wix-users@lists.sourceforge.net
Subject:
UK. VAT No. 821339546.
-Original Message-
From: Dave Moss [mailto:davidm...@omprompt.com]
Sent: 24 May 2013 09:12
To: Hoover, Jacob
Cc: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Major upgrade using bootstrapper issue -HELP!!
Hi Jacob,
I would like to start by saying thanks
es at 67 Innovation Drive, Milton Park, Abingdon,
Oxfordshire. OX14 4RQ. UK. VAT No. 821339546.
-Original Message-
From: Dave Moss [mailto:davidm...@omprompt.com]
Sent: 24 May 2013 09:12
To: Hoover, Jacob
Cc: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Major upgrade using boo
. VAT No. 821339546.
-Original Message-
From: Hoover, Jacob [mailto:jacob.hoo...@greenheck.com]
Sent: 23 May 2013 15:52
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Major upgrade using bootstrapper issue -HELP!!
Hmm,
The install logs would be helpful
No. 821339546.
-Original Message-
From: Dave Moss [mailto:davidm...@omprompt.com]
Sent: 24 May 2013 09:12
To: Hoover, Jacob
Cc: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Major upgrade using bootstrapper issue -HELP!!
Hi Jacob,
I would like to start by saying thanks for
jacob.hoo...@greenheck.com]
Sent: 23 May 2013 15:52
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Major upgrade using bootstrapper issue -HELP!!
Hmm,
The install logs would be helpful to know what is going on. Start with the
BA's log to see what it's detec
Park, Abingdon,
Oxfordshire. OX14 4RQ. UK. VAT No. 821339546.
-Original Message-
From: Hoover, Jacob [mailto:jacob.hoo...@greenheck.com]
Sent: 23 May 2013 15:52
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Major upgrade using bootstrapper issue -HELP!!
taller XML toolset.
Subject: Re: [WiX-users] Major upgrade using bootstrapper issue -HELP!!
Just for a bit of extra information if I run the bootstrapper install and then
run just the application msi for the upgrade it works fine so it seems to be an
issue from running the upgrade through the bootstrapp
No. 821339546.
>
> -Original Message-
> From: Hoover, Jacob [mailto:jacob.hoo...@greenheck.com]
> Sent: 23 May 2013 15:32
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Major upgrade using bootstrapper issue -HELP!!
>
> Is your ke
-Original Message-
From: Hoover, Jacob [mailto:jacob.hoo...@greenheck.com]
Sent: 23 May 2013 15:32
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Major upgrade using bootstrapper issue -HELP!!
Is your key path and/or component ids changing with each new installer
Is your key path and/or component ids changing with each new installer? Open up
two versions of your installer in Orca, and for any given file that isn't there
after the major upgrade compare the component ID's.
-Original Message-
From: Dave Moss [mailto:davidm...@omprompt.com]
Sent: Th
Chaitanya,
Best place to start is reading the documnetation.
First there is this is from the Wix Documentation
http://wix.sourceforge.net/manual-wix3/major_upgrade.htm
And then there is this from the excellent Wix Tutorial
http://wix.tramontana.co.hu/tutorial/upgrades-and-modularization
Beyond
gain.
Thanks,
Sheldon
-Original Message-
From: Nick Ramirez [mailto:nickra...@hotmail.com]
Sent: Friday, November 02, 2012 12:18 PM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Major Upgrade not working after changes to UIRef
Does the install log show that it is detecting
Does the install log show that it is detecting the old version?
At one point I thought that I had to schedule InstallExecute after
RemoveExistingProducts, but last I tried it that didn't seem to be the case.
Is it possible to switch to use the new MajorUpgrade element? It seems to
make life easi
ge-
> From: PKEuS [mailto:philipp.kl...@web.de]
> Sent: Thursday, October 25, 2012 3:57 PM
> To: wix-users@lists.sourceforge.net
> Subject: Re: [WiX-users] Major upgrade stops working after doing small
> changes and switching to 3.6
>
> I finally found the solution (by trial&a
re missing the VC runtime (may not be an issue, and not certain if burn
can support conditionally not elevating)
-Original Message-
From: PKEuS [mailto:philipp.kl...@web.de]
Sent: Thursday, October 25, 2012 3:57 PM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Major upg
I finally found the solution (by trial&error):
Its the VC CRT merge module I added. It requires per-machine install and
thus whole install scope changes.
Any ideas how to solve that (if possible with keeping installer per-user)?
--
View this message in context:
http://windows-installer-xml-wix
> Your previous install was per user, the new install is per machine, and one
will not upgrade the other. The Windows default if unspecified is per user,
so perhaps if you never set it in the original install it defaulted to per
user.
The question is: Why has the new one a different setting? I d
- it
may show why you got a per user install if you weren't expecting one.
Phil W
-Original Message-
From: PKEuS [mailto:philipp.kl...@web.de]
Sent: Sunday, October 21, 2012 2:50 AM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Major upgrade stops working after
Has nobody an idea what (and why) is going wrong?
As far as I can see, it doesn't find the old installation because of
conflicting InstallScope. But I have no idea, why install scope is different
(even if I explicitly set it).
--
View this message in context:
http://windows-installer-xml-wix-t
You can find verbose log file here:
http://kloke-witten.dyndns.org/~philipp/Temp/msi_log.zip
There are some lines about finding related products, where it says
"FindRelatedProducts: current install is per-machine. Related install for
product '{1CC8C271-A877-4DF0-B1DE-C1B7D83521BC}' is per-user.
If theUpgradeCode is stable then I don't see anything obvious. What does
verbose logfile for update show?
On Fri, Oct 19, 2012 at 9:05 AM, PKEuS wrote:
> Hello,
>
> First of all, sorry for posting this a second time, but my first post (via
> nabble) seems to have been rejected, because I hadn't
> Date: Thu, 30 Aug 2012 18:03:02 -0400
> From: mukeshj...@kpmg.com
> To: wix-users@lists.sourceforge.net
> Subject: [WiX-users] Major Upgrade changes requirement
>
> What changes we need to do for Major Upgrade
>
> Example - Product Code, Package Code, vers
Yes, basically.
On Thu, Aug 30, 2012 at 3:03 PM, Jain, Mukesh wrote:
> What changes we need to do for Major Upgrade
>
> Example - Product Code, Package Code, version etc... ??
>
>
> Thanks,
> Mukesh
>
>
>
> ANY TAX ADVICE IN THIS COMMUNICATION IS NOT INTENDED OR
> WRITTEN BY KPMG TO BE USED
al Message-
From: rajeshk [mailto:rajeshkannan.kr...@gmail.com]
Sent: 27 June 2012 12:45
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Major upgrade not working
I tried and reproduce the problem.I was follow the below steps.
1. I was installed new MSi version 1.0.0 2. I w
I tried and reproduce the problem.I was follow the below steps.
1. I was installed new MSi version 1.0.0
2. I was implemented minor upgrade and MSI version is 1.1.0
3. Then I tried for major upgrade (version 4.1.0).
First 2 steps are working fine, but when i tried for 3 step its throw the
error.A
I tried and reproduce the problem.I was follow the below steps.
1. I was installed new MSi version 1.0.0
2. I was implemented minor upgrade and MSI version is 1.1.0
3. Then I tried for major upgrade (version 4.1.0).
First 2 steps are working fine, but when i tried for 3 step its throw the
error.A
I tried and reproduce the problem.I was follow the below steps.
1. I was installed new MSi version 1.0.0
2. I was implemented minor upgrade and MSI version is 1.1.0
3. Then I tried for major upgrade (version 4.1.0).
First 2 steps are working fine, but when i tried for 3 step its throw the
error.A
That isn't an error. It is telling you that the component won't be removed
because a different MSI on the computer has also installed that component, so
the component is still needed.
It may be from a previous failed upgrade. Can you reproduce this error on a
clean virtual machine ?
-Original
Upgrade will set a property indicating that the major upgrade is expected.
You can use that to change your UI and I *think* (never tried) condition
out RemoveExistingProducts appropriately.
On Wed, Nov 16, 2011 at 5:23 AM, wrote:
> Hi,
>
> after some discussions I've changed my mind and have imp
wix-users@lists.sourceforge.net
> Subject: Re: [WiX-users] major upgrade from per-client to per-machine install
>
> Which per-user one ? There could be multiple per-user installations on a
> machine.
> You'd have to be an admin to detect the per-user installation of another
> us
rt of a chainer.
-Original Message-
From: Martin Kulov [mailto:mar...@kulov.net]
Sent: 13 October 2011 10:47
To: wix-users
Subject: Re: [WiX-users] major upgrade from per-client to per-machine install
Hi everyone, Is there a way to detect per-user installation and so that
per-machine install is p
05:56:50 -0700
> > To: wix-users@lists.sourceforge.net
> > Subject: Re: [WiX-users] major upgrade from per-client to per-machine
> > install
> >
> > Sadly, Windows Installer doesn't support that.
> >
> > On Mon, Oct 10, 2011 at 9:23 AM, Martin Kulov wrote:
>
Thanks Rob, Is there a way to detect this situation and prevent the per machine
installation in such case? Thanks,Martin > From: r...@robmensching.com
> Date: Tue, 11 Oct 2011 05:56:50 -0700
> To: wix-users@lists.sourceforge.net
> Subject: Re: [WiX-users] major upgrade from per-c
Sadly, Windows Installer doesn't support that.
On Mon, Oct 10, 2011 at 9:23 AM, Martin Kulov wrote:
>
> Hi, (moving this to a new thread) I have an existing MSI that needs to be
> MajorUpgrade'd from per client to per machine installation.Right now
> installing the latest bits results in two ve
Just wanted to say thanks for all the advice : the WIX_UPGRADE_DETECTED
condition worked well.
Sent: Monday, August 01, 2011 9:31 AM
To: 'wix-users@lists.sourceforge.net'
Subject: Major upgrade opt-out ?
We would like to be able to uninstall an older product, and install the new
version. I tri
olset.
Subject: Re: [WiX-users] Major upgrade opt-out ?
Condition your dialog on WIX_UPGRADE_DETECTED.
However, is unattended upgrade or an install important? If it is,
popping a dialog during an upgrade scenario is going to force an
attended install.
--
--
John Merryweather Cooper
Jack Henry & A
Condition your dialog on WIX_UPGRADE_DETECTED.
However, is unattended upgrade or an install important? If it is, popping a
dialog during an upgrade scenario is going to force an attended install.
--
--
John Merryweather Cooper
Jack Henry & Associates, Inc. (Premier Tech, Inc.)
Build & Install E
You could use the Upgrade element rather than MajorUpgrade. That would give you
a Property you can use in a Condition to display a dialog asking the user if
they want to continue with the upgrade or exit the installation process.
Palbinder Sandher
Software Deployment Engineer
T: +44 (0) 141 945
Yes the ini needs to be left behind on rollback and uninstall. With an
uninstall it is left behind as desired.
Changing the scheduling of RemoveExistingProductsdoes not have any effect.
It just seems strange that if the major upgrade does a uninstall then a
install why should a rollback of the
I expect it also depends how you schedule your Major Upgrade. If you remove
one MSI completely then install the second (early RemoveExistingProducts)
and that gets canceled, then I expect the file would be rolledback because
the second install is essentially a clean install.
If you schedule Remove
When you say "never removed even on rollback", do you mean never removed
on uninstall either?
If so, you can set your component's guid to an empty string. Meaning
Windows Installer will not "manage" the component at all - so it won't
be able to remove it.
But Windows Installer also won't be able
that will
clue us into what is really going wrong.
-Original Message-
From: fiordean dacian [mailto:dfiord...@yahoo.com]
Sent: Tuesday, September 28, 2010 1:44 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Major upgrade, MigrateFeatureStates &
I track what's happening in a couple of different logs (ie debugging
:)).
Thanks,
Dacian
--- On Tue, 9/28/10, Blair wrote:
From: Blair
Subject: Re: [WiX-users] Major upgrade, MigrateFeatureStates & custom action
To: "'General discussion for Windows Installer XML toolset.&#
acian [mailto:dfiord...@yahoo.com]
Sent: Saturday, September 25, 2010 4:41 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Major upgrade, MigrateFeatureStates & custom action
Hi Phil, thanks. Actually I wanted it that way, but I feel it's not the
problem at th
On 25-Sep-10 07:41, fiordean dacian wrote:
> Now back to my problem, can you see any problem in the log I posted below or
> is the fact that I'm using a UI and schedule MigrateFeatureStates which
> creates me problems?
The MigrateFeatureStates SDK doc describes its limitations, including:
The
From: Wilson, Phil
Subject: Re: [WiX-users] Major upgrade, MigrateFeatureStates & custom action
To: "General discussion for Windows Installer XML toolset."
Date: Friday, September 24, 2010, 8:01 PM
Setting MigrateFeatureStates means that you want to do an upgrade where the
features
ssage-
From: fiordean dacian [mailto:dfiord...@yahoo.com]
Sent: Friday, September 24, 2010 8:01 AM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Major upgrade, MigrateFeatureStates & custom action
Hi
I made a mistake when I copied the "FindRelatedProducts" in my initial
Hi
I made a mistake when I copied the "FindRelatedProducts" in my initial email.
Here is the correct text from the verbose log (we see the property
WIX_UPGRADE_DETECTED being correctly set to my initial installed product GUID)
Action start 16:44:52: FindRelatedProducts.
FindRelatedProducts: Fou
Blair-2 - thanks for your reply, and that'll be exactly what the problem is.
So one UpgradeCode Guid for all versions of one product? And I assume that
by having different ones, I've essentially told windows installer that each
msi represents an entirely different product. That will explain the tu
First cut: normally once you designate an UpgradeCode for whatever
represents a product, you never change it. Always use the same UpgradeCode
(Product/@Upgrade value) between your products that are intended to replace
each other/be mutually exclusive.
-Original Message-
From: fragorl [mail
Don't know. I suspect you still can't remove any found per-user installs
with RemoveExistingProducts, however.
-Original Message-
From: cemiles [mailto:chad.mi...@gmail.com]
Sent: Friday, January 15, 2010 11:48 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] major upgrade of p
Blair,
Thank you for your reply.
Now I think I've got the clear notion of GAC and SxS, and
how I should schedule RemoveExistingProducts.
And it's okay with the product-level versioning issues.
As for the component rules and the versioning rules of files,
I'll check them out in "TAO of Windows I
Inline...
-Original Message-
From: Kihara Nobuo [mailto:soft...@gmail.com]
Sent: Friday, January 08, 2010 6:43 PM
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] Major Upgrade, RemoveExistingProducts, Downgrade
Prevention and Component Guid
Hi all,
I'm new
Message-
From: Scott Palmer [mailto:swpal...@gmail.com]
Sent: Sunday, October 04, 2009 12:44 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Major Upgrade install - why are files missing?
Response inline...
On Sat, Oct 3, 2009 at 3:37 PM, Blair wrote
How long has the
problem been known? How many broken installs are out there that would "just
work" if this was fixed?
Thanks for your help!
Scott
> -----Original Message-
> From: Scott Palmer [mailto:swpal...@gmail.com]
> Sent: Saturday, October 03, 2009 4:32 AM
>
inal Message-
From: Scott Palmer [mailto:swpal...@gmail.com]
Sent: Saturday, October 03, 2009 4:32 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Major Upgrade install - why are files missing?
So it's a bug in Windows Installer - since it is doing tw
be able to author our
> file lists once, use stable component guids (and/or auto-generated ones),
> and place RemoveExistingProducts late (which is more efficient in several
> measures).
>
> -----Original Message-
> From: Scott Palmer [mailto:swpal...@gmail.com]
> Sent: Friday, Oc
nstaller XML toolset.
Subject: Re: [WiX-users] Major Upgrade install - why are files missing?
I have determined how to reproduce this problem.When the user runs the
installer it is possible that part of the application is still running.
That means there are files in use that the RemoveExisting task wan
Scott Palmer [mailto:swpal...@gmail.com]
> Sent: Monday, September 21, 2009 6:19 AM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Major Upgrade install - why are files missing?
>
> Getting back to the original problem. The files that were missing
M
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Major Upgrade install - why are files missing?
>
> Getting back to the original problem. The files that were missing after my
> major upgrade install were in a merge module that I created that
.
-Original Message-
From: Scott Palmer [mailto:swpal...@gmail.com]
Sent: Monday, September 21, 2009 6:19 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Major Upgrade install - why are files missing?
Getting back to the original problem. The files that
Getting back to the original problem. The files that were missing after my
major upgrade install were in a merge module that I created that was the
same in both products and therefore followed the component rules (since
there were no changes to the install path or content of any components).
Woul
s amongst components.
Have you profiled your setups to see where they are spending their time?
-Original Message-
From: Scott Palmer [mailto:swpal...@gmail.com]
Sent: Saturday, September 19, 2009 9:02 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Major Upgr
ent Rules.
>
> -Original Message-
> From: Scott Palmer [mailto:swpal...@gmail.com]
> Sent: Saturday, September 19, 2009 6:10 PM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Major Upgrade install - why are files
> missing?
>
>
1 - 100 of 148 matches
Mail list logo
