x27;t have to set the
neverovewrite.
From: Jeremiahf
Sent: 28 January 2015 16:59
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] Upgrading old installer
So you want to leave the old config file there? Will your new installer
configu
So you want to leave the old config file there? Will your new installer
configure the new config file and maintain it from there on?
On Wed, Jan 28, 2015 at 8:15 AM, Kraygsoft
wrote:
> Anyone
>
>
>
> --
> View this message in context:
> http://windows-installer-xml-wix-toolset.687559.n2
Anyone
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Upgrading-old-installer-tp7599052p7599055.html
Sent from the wix-users mailing list archive at Nabble.com.
, Blaine (DSHS/DCS) [mailto:bwhee...@dshs.wa.gov]
Sent: Monday, October 27, 2014 14:57
To: 'General discussion about the WiX toolset.'
Subject: Re: [WiX-users] Upgrading Burn bootstrapper with msi
Windows Installer can remove the bootstrapper for you. Use the Windows
Installer FindRelat
Windows Installer can remove the bootstrapper for you. Use the Windows
Installer FindRelatedProducts action with the bootstrappers UPGRADECODE and
version.
-Original Message-
From: Mihailo Milenković [mailto:mihailo.milenko...@pstech.rs]
Sent: Monday, October 27, 2014 4:08 AM
To: w
On 28-Jul-14 08:51, Chetan Dabade wrote:
> i scanned my whole machine but couldn't find file "*Common.wxs*" and in
> addition under Installer.wxs file there is a variable declared as:
>
>
> **
> while googling i found the above mentioned error
>
> http://www.joyofsetup.com/2010/05/20/its-time-to-
Hi all,
I found the issue and fixed it. The issue was under each .wixproj file the
value of $(WixToolPath) was referring to older version of Wix (.i.e 3.5)
$(ProgramFiles)\Windows Installer Xml
v3.5\bin\
I re-visited each individual projects unloaded it, edit the .wixproj file
and change the
Thanks I have add the "older" MSI's upgrade code to the upgrade table and will
test that tomorrow :)
Cheers,
STeve
-Original Message-
From: Phill Hogland [mailto:phogl...@rimage.com]
Sent: June-09-14 4:46 PM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users]
I do not have direct experience with this issue, but I suspect the thing to
do is to leave the new package name as is, but rather author multiple
upgrade codes to also remove the old product.
http://www.joyofsetup.com/2008/09/07/hint-be-generous-with-upgrade-codes/
--
View this message in conte
what if at build time I change the name of the MSI to be the same as the
original MSI's name and use the same upgrade code?
Would that work ?
Steve
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Upgrading-tp7595079p7595124.html
Sent from the wix
Your Second Option is Best, if not you will have a side by side install
Quoting Steve-Ogilvie :
> I have a quick question...
>
> We released 4.2.0.x about 3 months ago. and our Services MSI was named
> TITUS_Services_Setup_x86 we shipped only the 32 bit services with our Client
> installer with a
See
https://wix.codeplex.com/SourceControl/network/forks/jchoover/Wix?branch=instances
and/or
https://wix.codeplex.com/SourceControl/network/forks/patoshea/InstanceTransforms/contribution/4700.
Both are essentially the same reapplication of my prior contribution setup for
3.8. I'll submit m
Jacob [mailto:jacob.hoo...@greenheck.com]
Sent: 28 March 2013 15:42
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Upgrading an Install fails to downgrade a 3rd party
library
I don't like any of these per say, but just throwing some ideas out for you to
ponder/try.
:24
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Upgrading an Install fails to downgrade a 3rd party
library
You could try scheduling remove existing products earlier, after
InstallInitialize.
-Original Message-
From: Jackson Pope [m
t: Re: [WiX-users] Upgrading an Install fails to downgrade a 3rd party
library
You could try scheduling remove existing products earlier, after
InstallInitialize.
-Original Message-
From: Jackson Pope [mailto:jackson.p...@nonlinear.com]
Sent: Thursday, March 28, 2013 3:28 AM
To: wix-
You could try scheduling remove existing products earlier, after
InstallInitialize.
-Original Message-
From: Jackson Pope [mailto:jackson.p...@nonlinear.com]
Sent: Thursday, March 28, 2013 3:28 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Upgrading an Install fails to dow
nfig
files - generate them in the application from defaults if they aren't
present.
-Original Message-
From: Benjamin Kaduk [mailto:ka...@mit.edu]
Sent: 19 September 2012 20:04
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] upgrading from 64-bit to 32-bit product leavesfiles
beh
Bob Arnson wrote:
> Benjamin Kaduk wrote:
> > I'm really confused by this behavior, and don't know where to look
> > further.
> The verbose upgrade log. It will tell you why MSI decided to leave a
> ile behind.
The problem is, as far as I can tell from the verbose upgrade log, MSI
does not think
On Tue, Sep 18, 2012 at 8:17 PM, Bob Arnson wrote:
> On 18-Sep-12 16:24, Benjamin Kaduk wrote:
>> I'm really confused by this behavior, and don't know where to look
>> further.
> The verbose upgrade log. It will tell you why MSI decided to leave a
> file behind.
If it decided to do so. It could a
On 18-Sep-12 16:24, Benjamin Kaduk wrote:
> I'm really confused by this behavior, and don't know where to look
> further.
The verbose upgrade log. It will tell you why MSI decided to leave a
file behind.
--
sig://boB
http://joyofsetup.com/
--
The out of the box bootstrappers provided by Wix currently doesn't have a
feature tree to drive the MSI's. You could show your MSI UI, but that would
deter from the single unified installation experience.
If you have a single MSI that has no prerequisites then using burn would only
allow you f
On Wed, Sep 14, 2011 at 7:46 PM, Bob Arnson wrote:
> On 14-Sep-11 19:12, Daniel Pratt wrote:
> > uninstall mode. I've tried many different permutations of command lines,
> but
> > the typical error message is "Invalid command line argument. Consult the
> > Windows Installer SDK for detailed comm
On 14-Sep-11 19:12, Daniel Pratt wrote:
> uninstall mode. I've tried many different permutations of command lines, but
> the typical error message is "Invalid command line argument. Consult the
> Windows Installer SDK for detailed command line help".
>
> Now I suppose that this error message is tr
Hi Daniel
With a Major Upgrade you are essentially installing a new product and
uninstalling an old one, so I found the commandline needed the MSINEWINSTANCE=1
set for upgrading the instance.
Also try searching the Wix-Users email archive as there are some very good
emails on how people have
From: Christopher Painter [mailto:chr...@deploymentengineering.com]
Sent: 15 January 2011 13:20
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] upgrading custom actions to be data driven
Before I begin describing how to refactor hard wired custom actions to data
d
Before I begin describing how to refactor hard wired custom actions to data
driven custom actions, I have to ask: Can your problem be solved using
Windows Installer's built-in Condition table? What is unique about your story
that requires a custom action in the first place?
Christopher Pa
discussion for Windows Installer XML toolset.
Onderwerp: Re: [WiX-users] Upgrading wixproj
Unfortunately, no.
That build was a (now very old) intermediate release. We don't save
intermediate releases for very long. We don't have the resources to
support
drops at all points in t
Unfortunately, no.
That build was a (now very old) intermediate release. We don't save
intermediate releases for very long. We don't have the resources to support
drops at all points in time of the development cycle. If you're using the
the "development branch" of the WiX toolset (which both WiX v
Thanks Rob,
I'd like to avoid having to upgrade all our projects at this time. Is
there a version at http://wix.sf.net/releases that will work with my
\Microsoft\WiX\v3.5\Wix2010.targets style wix projects?
-Eric
On Wed, Jan 5, 2011 at 2:31 AM, Rob Mensching wrote:
> And to answer the actual
Yes, we switched to "v3.x" in hopes that the VS project system will not have
an upgrade in WiX v3.6 and later.
There were a great many changes in VS2010 that caused the project system
upgrade. It's painful and hopefully we've done the work necessary to not
need another one for the life of WiX v3.x
And to answer the actual question, I think 3.5.1419 has rolled off. That
build is almost a year out of date, we don't keep development builds around
for more than a few months typically (and less when we get to Escrow like
with WiX v3.5).
On Tue, Jan 4, 2011 at 11:30 PM, Rob Mensching wrote:
> W
Weekly release are at http://wix.sf.net/releases. Yes, I know, we need to
clean all this stuff up. Sorry.
Eventually http://wixtoolset.org will have all the information.
On Tue, Jan 4, 2011 at 2:14 PM, Eric Goforth wrote:
> Hmmm, I'm on codeplex (http://wix.codeplex.com/releases/view/44406)
>
Hmmm, I'm on codeplex (http://wix.codeplex.com/releases/view/44406)
right now and I don't see a way to download 3.5.1419, is it possible
to do that? I checked out http://wixtoolset.org/ too, but it looks
like that's just a place-holder site for now.
-Eric
On Tue, Jan 4, 2011 at 5:03 PM, Eric Gof
Thanks, it looks like he has 3.5.1419, I have 3.5.2415.
On Tue, Jan 4, 2011 at 4:40 PM, jhennessey wrote:
>
> All builds will say "Windows Installer XML Toolset 3.5" but you need to check
> the actual build version (I think the latest is 3.5.2430.0).
>
> v3.x\Wix.targets is what is current
> --
>
All builds will say "Windows Installer XML Toolset 3.5" but you need to check
the actual build version (I think the latest is 3.5.2430.0).
v3.x\Wix.targets is what is current
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Upgrading-wixproj-tp58900
Hello,
I looked at the other developer's add/remove programs, it showed the
same version as mine:
Windows Installer XML Toolset 3.5
Before the "upgrade," I see:
$(MSBuildExtensionsPath)\Microsoft\WiX\v3.5\Wix2010.targets
In the .wixproj file, after the "upgrade," I see:
$(MSBuildExtensionsPat
It looks like they have an older version of 3.5 installed than you do. I
believe it used to v3.5 but was later switched to use v3.x. If you both
install the same version it should solve your problem.
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/U
it at all from the InstallExecuteSequence.
>>
>> If the other setup package is not-at-all MSI, there is nothing to pass
>
>> to Windows Installer, since WI can only deal with MSI packages, and
>> you will need to execute the uninstall executable somehow/somewhere.
>>
&g
[mailto:lukasha...@gmx.at]
Sent: 26 July 2010 11:44
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Upgrading from other setup program to WiX/MSI
Hi,
I changed my approach a little bit. For reference:
This is what I added to my wxs file:
And this is my small CheckSpecialist.c
Dear dB,
Thank you for your comment. You are right, maybe a bootstrapper would
have been the better apporach ...
I will have a look at dotNetInstaller.
Am 23.07.2010 16:43, schrieb dB.:
> Having dealt with a similar scenario with InstallShield, the best I can
> suggest is to bootstrap uninstal
x.at]
> Sent: Sunday, July 25, 2010 5:18 AM
> To: wix-users@lists.sourceforge.net
> Subject: Re: [WiX-users] Upgrading from other setup program to WiX/MSI
>
> Dear Blair,
>
> Thank you for the hint! I will replace my MessageBox-call prompt with
> MsiProcessMessage/WcaProcessM
l executable somehow/somewhere.
-Original Message-
From: Lukas Haase [mailto:lukasha...@gmx.at]
Sent: Sunday, July 25, 2010 5:18 AM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Upgrading from other setup program to WiX/MSI
Dear Blair,
Thank you for the hint! I will replace my Me
> From: Lukas Haase [mailto:lukasha...@gmx.at]
> Sent: Thursday, July 22, 2010 12:47 PM
> To: wix-users@lists.sourceforge.net
> Subject: Re: [WiX-users] Upgrading from other setup program to WiX/MSI
>
> Dear Blair,
>
> Am 22.07.2010 01:04, schrieb Blair:
>> 1. You can b
Having dealt with a similar scenario with InstallShield, the best I can suggest
is to bootstrap uninstall. You can use dotNetInstaller
(http://dotnetinstaller.codeplex.com) and write a command line that will
uninstall the previous application. Write an MSI to uninstall the legacy thing
or write
M
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Upgrading from other setup program to WiX/MSI
Dear Blair,
Am 22.07.2010 01:04, schrieb Blair:
> 1. You can build MSIs with WiX that don't require running the setup as
> administrator. Nothing that can be done outside of Windows Installer
wi
Dear Blair,
Am 22.07.2010 01:04, schrieb Blair:
> 1. You can build MSIs with WiX that don't require running the setup as
> administrator. Nothing that can be done outside of Windows Installer without
> elevation requires elevation in Windows Installer to also do.
In fact this is exactly what I do
1. You can build MSIs with WiX that don't require running the setup as
administrator. Nothing that can be done outside of Windows Installer without
elevation requires elevation in Windows Installer to also do.
2. Windows Installer has no built-in support for detecting/removing non-MSI
packages. Ho
, November 23, 2009 4:21 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Upgrading
That's known as a Minor Update but it's only one of the available upgrade
types.
See http://msdn.microsoft.com/en-us/library/aa370579.aspx
Palbinder Sandher
Soft
t: 21 November 2009 10:59
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Upgrading
Sorry.. the solution was to execute the msi like this:
msiexec.exe /I product.msi REINSTALL=All REINSTALLMODE=vomus
So I am not stuck anymore.
Regards,
Daniel
Daniel Marjamäki wrote:
>
>
Sorry.. the solution was to execute the msi like this:
msiexec.exe /I product.msi REINSTALL=All REINSTALLMODE=vomus
So I am not stuck anymore.
Regards,
Daniel
Daniel Marjamäki wrote:
>
> I am having trouble with upgrades.
> Upon installation I want to completely uninstall any old versions.
According to wix.chm, File isn't a valid parent element for
util:PerformanceCounter. It needs to be under a Util:PerformanceCategory
element, which in turn needs to be under a Component element, not a File.
See the CHM for more information.
Thanks,
Mike Carlson
-Original Message-
From:
Few options available here and you can find more using search engine of your
choice:
Neil Sleightholm's blog:
-
http://neilsleightholm.blogspot.com/2009/01/wix-script-for-major-upgrades.ht
ml
My take on it:
-
http://blogs.technet.com/alexshev/archive/2008/02/15/from-msi-to-wix-part-8-
major
Take at look at the WiX tutorial at
http://www.tramontana.co.hu/wix/lesson4.php
This has some detail on doing upgrades. That should start you on your
way.
Chris
-Original Message-
From: John D. Marinuzzi [mailto:nu...@hypack.com]
Sent: Wednesday, July 22, 2009 13:12
To: wix-users@lis
Murray
I know there is some stuff if you search through the history of this mailing
list. I don't know of any tutorials or other info, but that doesn't mean there
isn't any.
First what runs in an upgrade is really going to depend on if you are doing an
MSI Major Upgrade or Minor Upgrade. If
com>
From: Sudripta Nandy (Sarangsoft Corporation) [mailto:v-su...@microsoft.com]
Sent: Thu 02/04/2009 01:40
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Upgrading an older version of product
Thanks Phil.
Your have hit the bullseye. You are right. I saw the log
.
Sudripta.
Re: [WiX-users] Upgrading an older version of
product<http://sourceforge.net/mailarchive/message.php?msg_name=5C889913FF236E4190093AF280AB4EC40167E7E295%40wwlkfmail1.wonderware.com>
From: Wilson, Phil - 2009-04-02 00:09
It's nothing to do with the same user account. It&
Sent: Wednesday, April 01, 2009 4:53 PM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Upgrading an older version of product
The older version hadn't any ALLUSERS value set. The new version has ALLUSERS
set to 1. But, I am installing both the versions from the same user account
Hi
Have you remembered to add "SecureCustomProperties" to your property table?
(Or does candle/light do that for you??)
K.
Yes, I have the following element defined within InstallExecuteSequence of
version 2.0.1000.0.
Another thing is that in the new version of the product, I have comp
n't any 'ARPNOREMOVE' property. The new version hasn't got any of
the property.
Thanks.
Sudripta.
Re: [WiX-users] Upgrading an older version of
product<http://sourceforge.net/mailarchive/message.php?msg_name=5C889913FF236E4190093AF280AB4EC40167E7E22F%40wwlkfmail1.wonderwa
thing is that the product name is
also different in the new version. The only similarity between the two versions
is the upgrade code.
Thanks.
Sudripta.
Re: [WiX-users] Upgrading an older version of
product<http://sourceforge.net/mailarchive/message.php?msg_n
discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] Upgrading an older version of product
Do you have a RemoveExistingProducts action defined in your execution sequence?
Jim Williams
-Original Message-
From: Sudripta Nandy (Sarangsoft Corporation) [mailto:v-su..
Do you have a RemoveExistingProducts action defined in your execution sequence?
Jim Williams
-Original Message-
From: Sudripta Nandy (Sarangsoft Corporation) [mailto:v-su...@microsoft.com]
Sent: Wednesday, April 01, 2009 4:03 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Up
Hi Thanks for reply.
I refered the link send by you.
first thing I don't want major upgrade. But still I tried with major upgrade
also.
But it didn't work. same error as
"Another version of this product is already installed. Installation of this
version cannot continue. To configure or remove the e
Are you changing Product/@Id on each build? There is an example of a
major upgrade script here:
http://neilsleightholm.blogspot.com/2009/01/wix-script-for-major-upgrade
s.html
Neil
-Original Message-
From: Hukumchand Shah [mailto:hukum.s...@gmail.com]
Sent: 21 March 2009 07:27
To: Gener
MSI SDK about Major Upgrades (and others) has pretty much step by step
instructions when the various GUIDs change. It is very terse reading, so it
takes a few times to get all the pieces but that data is there.
The way I think about it, Upgrade code is a "family" marker. The Upgrade code
draw
The permanent setting should still allow updates based on file version.
Hopefully you didn't set the "never overwrite" flag.
Phil Wilson
-Original Message-
From: John Lalande [mailto:[EMAIL PROTECTED]
Sent: Friday, December 05, 2008 12:38 PM
To: wix-users@lists.sourceforge.net
Subje
Craig0ss wrote:
> What about a component search, if it finds the product it fills the
> keypath??
>
Should work. I've never tried it.
--
sig://boB
http://joyofsetup.com/
-
This SF.net email is sponsored by: Splunk Inc.
hmmm
What about a component search, if it finds the product it fills the
keypath??
Ive read this but am unsure on how to execute this my self
thanks
Bob Arnson-6 wrote:
>
> Craig0ss wrote:
>> I need my MSI to check for an existing install of the software ie. 5.2.1,
>> now it does this fine
> From: Craig0ss
> Sent: Monday, November 05, 2007 12:01 PM
>
> Ive read alot of other posts regarding upgrading but ive yet
> to find any
> information relavent to my situation, so if anyone knows of
> any threads and
> have the links to them then please post. Here is what i want to do
>
> I n
Craig0ss wrote:
> I need my MSI to check for an existing install of the software ie. 5.2.1,
> now it does this fine, however i also need it to check for the existing
> directory and then pass that information to a variable that the installer
> then sets the installer to install to. Basically i need
Mike, Phil -
Thanks for the quick responses !
After some more testing, it appears to be a problem with how InstallShield
is consuming the merge modules ... not with how they're built.
Now I just need to convince another development group to use WiX ...
Regards,
-dmm
--
View this message i
The policy config file should have a file version entry pointing to the
policy assembly Dll (companion files) to make sure that the config file
piece of the assembly (it's a multi-file assembly) is also installed
when the Dll is installed (updated in this case).
(I assume you've got them both in
Publisher policy assemblies are also versioned. You must increase the
version number of the policy assembly for it to be added to the GAC in
addition to the version already there.
There are rules on the naming of the publisher policy assembly - if I recall
correctly, the major.minor of the policy
Two answers:
1) use " in your xml, that should evauluate to " at runtime.
4)you have to put in "ICE64", not just "64". If you look at the build output,
you can see the command lines that get generated for light and candle. If you
look there, you'll see that the ICE you put in that field is bei
D] *On Behalf Of *Aaron Feng
*Sent:* Thursday, January 04, 2007 07:47
*To:* Bob Arnson; wix-users@lists.sourceforge.net
*Subject:* Re: [WiX-users] Upgrading not doing anything
Bob,
I'm having a lot of problems trying to do minor upgrade. Partly the MSI
is automated using a custom in h
creating their
Components.
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Aaron Feng
Sent: Thursday, January 04, 2007 07:47
To: Bob Arnson; wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Upgrading not doing anything
Bob,
I'm having a lot of problems trying to do
You might check out:
http://robmensching.com/blog/archive/2007/01/04/Doing-a-small-update-or-minor-upgrade-in-MSI-Use.aspx
for more information.mailto:[EMAIL PROTECTED] On Behalf Of Bob Arnson MSI (s) (80:D4) [09:18:15:862]: Feature:
Client; Installed: Advertise; Request: Reinstall; Action:
f Bob Arnson
Sent: Thursday, January 04, 2007 7:41 AM
To: Aaron Feng
Cc: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Upgrading not doing anything
Aaron Feng wrote:
> Just for my understanding, what does Featuring marked as advertised
mean?
The MSI SDK talks about it starting at
http
Bob,
I'm having a lot of problems trying to do minor upgrade. Partly the MSI is
automated using a custom in house tool I wrote, so I have less control over
it.
I might just have to do a major upgrade every time. Is there any side
effect by doing so?
Thanx,
Aaron
On 1/4/07, Bob Arnson <[EMAI
Aaron Feng wrote:
> Just for my understanding, what does Featuring marked as advertised mean?
The MSI SDK talks about it starting at
http://msdn2.microsoft.com/en-us/library/aa367548.aspx.
--
sig://boB
http://bobs.org
-
T
Bob,
Just for my understanding, what does Featuring marked as advertised mean?
Thanx,
Aaron
On 1/4/07, Bob Arnson <[EMAIL PROTECTED]> wrote:
Aaron Feng wrote:
> MSI (s) (80:D4) [09:18:15:862]: Feature: Client; Installed:
> Advertise; Request: Reinstall; Action: Reinstall
This indicates
Aaron Feng wrote:
> MSI (s) (80:D4) [09:18:15:862]: Feature: Client; Installed:
> Advertise; Request: Reinstall; Action: Reinstall
This indicates what is probably the root of the problem. Features marked
as advertised aren't actually installed on the machine so an upgrade
doesn't do anythin
Thanks Bob, I will provide the information below. Hopefully someone can
figure it out.
All the information I provided below are related to the upgrade using the
MSI. I installed the first version by simply clicking on the "older" MSI.
The MSI I'm trying to do a minor upgrade with has a differen
Aaron Feng wrote:
> I'm not sure what information I need to provide here, since I'm not
> getting any error messages.
General info: The command lines you're using to install and upgrade.
Excerpts from verbose logs, especially around InstallValidate (as
Michael points out).
--
sig://boB
http
d.
Phil Wilson
--
*From:* [EMAIL PROTECTED] [mailto:
[EMAIL PROTECTED] *On Behalf Of *Michael Osmond
*Sent:* Wednesday, January 03, 2007 4:57 PM
*To:* Aaron Feng; wix-users@lists.sourceforge.net
*Subject:* Re: [WiX-users] Upgrading not doing anything
Aaron,
Have you tri
Michael,
I checked the log file, and I didn't see anything interesting, however, I
didn't check the InstallValidate and InstallFiles action closely. I didn't
use the /lv* switch on the log file, I just used the default. I can try it
again when I get back to work.
Yes, all my components have GU
27;t be any code files
updated.
Phil Wilson
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Michael
Osmond
Sent: Wednesday, January 03, 2007 4:57 PM
To: Aaron Feng; wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Upgrading not doing anything
Aaron,
Have you t
Aaron,
Have you tried logging the upgrade process, the command line option I
use is /lv* (which is just about everything).
Then look at two things:
1. The InstallValidate action - this should show what the installer is
planning to do to each component.
2. Then look for the actual InstallFil
88 matches
Mail list logo
