Hey all -
I've been having some problems installing wix 3.8 with avast running -
it seems to believe that wix 3.8 is a virus, and that installers
generated using it are too. It's reporting my builds as Win32:MalOb-CA
now. Anyone else having this problem?
--
Why are you setting TARGETDIR with a custom action?This is not usually a
good practice, and overriding TARGETDIR is usually reserved for activities like
admin installs. If you want to set up a variable InstallLocation, there are
much better patterns to follow to achieve this.
--
John Merry
With the EventSource node removed:
Action 16:25:34: SetTARGETDIR.
Action start 16:25:34: SetTARGETDIR.
MSI (c) (94:34) [16:25:34:197]: PROPERTY CHANGE: Modifying TARGETDIR property.
Its current value is 'C:\'. Its new value: 'C:\Program Files\Ent Federal Credit
Union\'.
MSI (c) (94:34) [16:25:34
>From the log file it seems my custom action that sets the TARGETDIR is the
>thing throwing the error:
Action 16:03:18: SetTARGETDIR.
Action start 16:03:18: SetTARGETDIR.
MSI (c) (58:18) [16:03:18:241]: PROPERTY CHANGE: Modifying TARGETDIR property.
Its current value is 'C:\'. Its new value: 'C:
Did you create a verbose log when you ran the uninstall? What did that log say?
Did you see my reply on this thread where I asked about the log?
> From: balu.mam...@flightsafety.com
> To: wix-users@lists.sourceforge.net
> Date: Wed, 31 Jul 2013 17:26:28 -0400
> Subject: Re: [WiX-users] Need to h
Thanks for that, I am just learning WiX and did not know how to make a log
file, but now I do.
AppSearch: Property: NETFRAMEWORK20INSTALLROOTDIR64, Signature:
NetFx20InstallRootSearch64
MSI (c) (58:18) [16:03:18:222]: Note: 1: 2262 2: Signature 3: -2147287038
MSI (c) (58:18) [16:03:18:222]: Note
So, what does NETFRAMEWORK20INSTALLROOTDIR64 evaluate to from the install log?
--
John Merryweather Cooper
Build & Install Engineer - ESA
Jack Henry & Associates, Inc.®
Shawnee Mission, KS 66227
Office: 913-341-3434 x791011
jocoo...@jackhenry.com
www.jackhenry.com
-Original Message-
I would like to add this node to my component, to make sure a specific event
source exists:
I have these also:
Just in case adding more of them would make the problem go away.
And this:
xmlns:util="http://schemas.microsoft.com/wix/UtilExtension";
The project builds, but as soon as the msi
Any other suggestions? This is last bug to send to LIVE..
-Original Message-
From: Mamidi, Balasubrahmanyam
Sent: Wednesday, July 31, 2013 12:33 PM
To: 'General discussion for Windows Installer XML toolset.'
Subject: RE: [WiX-users] Need to help! Uninstall the MSI on windows 7
Yes folde
There is an example here that might help:
http://neilsleightholm.blogspot.co.uk/2008/08/customised-uis-for-wix.html
-Original Message-
From: Tony White [mailto:twh...@ent.com]
Sent: 31 July 2013 21:11
To: 'wix-users@lists.sourceforge.net'
Subject: [WiX-users] Having trouble modifying a
Classification: Public
I had the license agreement in mine but moved the license agreement to the
bootstrapper (bundle) Do you have the licenseagreement dialog listed at all?
Where is your Next control event for the InstallDirDlg?
This is what I have:
You're going to end up with an InstallDir overlayed with your Publish
changes--this is not a recipe for success. The way that works is to take the
InstallDir UI from source, modify it to your liking, and that put a in
your product.wxs to a unique Id for your customized version of the InstallDi
I posted this on stackoverflow
http://stackoverflow.com/questions/17952469/having-trouble-modifying-a-built-in-wixui-dialog-set
with no answers yet, so I thought I would try here.
I am trying to hide the license agreement from the built-in WixUI_InstallDir
dialog set. I found some helpful instr
Classification: Public
A.) On a 64 bit machine running 32 bit Office, we install the 32 bit MSI for
out Plugins installer and our Client install
b) The component and file ID is different for both files one is cmp_filename
the other is cmp_filename_x64, and file_filename the other file_filename_x
A) Ok, then you should probably have a conditional Condition element on the 32
bit install to prevent the 32 bit MSI from installing on a 64 bit PC.
B) Knowing that,
This will cause both the 64 bit and 32 bit components to have the same ID's but
since you won't support both on the same PC
Classification: Public
I build the solution twice, once as ReleaseX86 and then again for ReleaseX64
(produces 2 MSI's, i.e. install_x86.msi, install_x64.msi) to answer:
Will happen at COMPILE/LINK time, so you will need to build the same project
twice. Once as 32 bit and once as 64 bit.
To answ
I'm confused...
Will happen at COMPILE/LINK time, so you will need to build the same project
twice. Once as 32 bit and once as 64 bit.
As for
I would ask a few things:
A) do you need to support both 32 bit and 64 bit components on t
>
That doesn't make much sense because $(var.Platform) is compile time. For an
x64 build, it's like you wrote:
(and x86 is )
This could be simplified to "VersionNT64"
Dave
--
Get your SQL database under version c
Classification: Public
Nuts more files to change roger that, will change :)
-Original Message-
From: John Cooper [mailto:jocoo...@jackhenry.com]
Sent: July-31-13 2:05 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Need help, how to put a condition on
I have a very similar include file in the installer that must build two
platforms. The only difference is that I replace $(var.Platform) with
$(sys.BUILDARCH). It has worked in production for nearly two years that way.
--
John Merryweather Cooper
Build & Install Engineer - ESA
Jack Henry & Ass
Classification: Public
Sigh, every example I see out there in Google land they use
And also this?
So your saying replace $(var.Platform) with $(sys.BUILDARCH) since the above
code should run at runtime...
-Original Message-
From:
Yes, it appears to be inverted.
Also, as the documentation states, $(sys.BUILDARCH) is a better choice than
$(var.Platform).
--
John Merryweather Cooper
Build & Install Engineer - ESA
Jack Henry & Associates, Inc.®
Shawnee Mission, KS 66227
Office: 913-341-3434 x791011
jocoo...@jackhenry.com
w
Yes folder exists after rebooted.
Thanks..
-Original Message-
From: Hoover, Jacob [mailto:jacob.hoo...@greenheck.com]
Sent: Wednesday, July 31, 2013 11:58 AM
To: General discussion for Windows Installer XML toolset.
Cc: General discussion for Windows Installer XML toolset.
Subject: Re: [
That "should" work, remembering you need both a 32bit and a 64 bit MSI. Though
I do think you have the MergRef's inverted based on the condition...
-Original Message-
From: David Watson [mailto:dwat...@sdl.com]
Sent: Wednesday, July 31, 2013 11:48 AM
To: General discussion for Windows I
Is the folder there after a reboot?
Sent from my iPhone
On Jul 31, 2013, at 11:16 AM, "Blair Murri" wrote:
> What does the log say?
> Most often it is that a file was held by something (usually anti-virus) but
> released before the transaction finished (the file was thus deleted by the
> time
Sorry I may have confused the issue by stating how I did it, the main
question was does this (or something similar) not work ?
Along the lines of
-Original Message-
From: Steven Ogilvie [mailto:steven.ogil...@titus.com]
Sent: 31 July 2013 17:26
To: General discussion for Window
Merge modules don't have the concept of "condition". You put the condition
on every component in the merge module or you put the condition on the
feature(s) that reference the merge modules (and hence the components ).
Once merged, a merge module doesn't exist. It's a build time concept not
Classification: Public
Can't use WIXLIBS to replace the MERGEMODULES (Rob confirmed that with me)
I am installing 5 Services, they each go into a separate folder off the
Services parent folder.
They share 8-10 WIXLIBS each (common files for each service, didn't make sense
to create new componen
What does the log say?
Most often it is that a file was held by something (usually anti-virus) but
released before the transaction finished (the file was thus deleted by the time
everything finished).
Is it very reproducible?
> From: balu.mam...@flightsafety.com
> To: wix-users@lists.sourceforge
I write installation sources all the time where the very same WXS files (and in
fact the very same WIXPROJ files) are used to make both configurations. A very
small amount of conditionals goes a long ways to making that work.
> From: steven.ogil...@titus.com
> To: wix-users@lists.sourceforge.net
I did it by not using merge modules, I used pure wixlibs.
http://wyrdfish.wordpress.com/2011/01/05/32-and-64-bit-msis-from-a-single-sou
rce-file/
So my components are pulled into the msi by ComponentGroupRef not by MergeID.
I only have the relevant bitness wixlib referenced in the wixproj.
Can
HI, when uninstall the msi package no issues on windowsXP( it deletes all
folders/subfolders/files etc..)
When I do the same thing on Wndows 7 , it just left ONE sub folder, but deletes
all files with in that...(can say EMPTY folder)
Any guess what is causing for NOT DELETING THAT SUB FOLDER?
Thank you for the response. It is very helpful.
Phill
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Patch-Best-practice-using-fragments-tp7587660p7587722.html
Sent from the wix-users mailing list archive at Nabble.com.
-
Classification: Public
I originally have two solutions for the Services installer, in the x86
product.wxs I have the 5 x86 merge modules, in the x64 product.wxs I have the 5
x64 merge modules...
So there are two sets of merge modules x86 compiled and x64 compiled
I am trying to make 1 solution u
34 matches
Mail list logo
