I am writing a wix project to deploy a website.
I am using the element.
If the CertificatePath is not correct , or the PFXPasswordis not correct,
the installation failed, but the installer didn't prompt error message. I
could only find the error in the log file.
Is there any way to prompt the u
There is some high level discussion about the value of signing right now. It
came up in relation to WIXBUG:4243 - http://wixtoolset.org/issues/4243/.
-Original Message-
From: Wesley Manning [mailto:wmann...@dynagen.ca]
Sent: Wednesday, January 8, 2014 1:09 PM
To: General discussion about
My patches are whole file patches.
There is no UI either in the patches either.
I'll have to check out the hash table and see what files may mismatch. It
never mentions anything about the file it's trying to access, it just keeps
mentioning the product it looking for. About every 45 seconds the
--
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into you
So you mean set SuppressSignatureVerification=yes in the MSIPackage,
ExePackage,... ?
Looks like I'm going to have to make a change although I don't do this and had
no problem so far. .
Wes
-Original Message-
From: Blair Murri [mailto:os...@live.com]
Sent: January-08-14 7:10 AM
To: G
Are your patches delta or whole file?
> Date: Wed, 8 Jan 2014 10:46:06 -0800
> From: phildgwil...@gmail.com
> To: wix-users@lists.sourceforge.net
> Subject: Re: [WiX-users] Patching compressed VS uncompressed image?
>
> It could be useful to examine the log where the patching accesses the
> netw
It could be useful to examine the log where the patching accesses the
network MSI to see what actually happens. Typical reasons include installed
files that no longer match the cached MSI. For example the cached (MSI plus
patches) has entries in the file table that say the version of the file on
di
The 3rd field is our "patch level" indicator. So, in marketing speak v1.1
Patch 1 is really v1.1.1.. They could use the minor version for
that, and change major versions more often, but they don't.
Thanks for all of the suggestions. I'll come up with something, or just
let everyone "deal wit
The easiest and cleanest way is to make the daily builds update the build
number (third part of the msi product version) each build and implement major
upgrade with a * product code (if you don't already)? Then dev builds always
install and remove any previous build.
You alter the product code
While this is not an MSI chain, I did the following in a bootstrapper as I
needed to make sure vcredist_x86 was installed before something else in the
program setup:
http://schemas.microsoft.com/wix/2006/wi";
xmlns:util="http://schemas.microsoft.com/wix/UtilExtension";>
While the approach I gave earlier is doable, I tend to agree here in
the DevLab only. When Going into Production, just downgrade the Build
Number to the last stable build, and whatever else you add...
The approach from earlier adds overhead, and won't be needed in the
production WiX file.
Exactly. Adding overhead to your install to fight the Windows Installer isn't
the right tradeoff, IMHO.
-Original Message-
From: Carter Young [mailto:ecyo...@grandecom.net]
Sent: Wednesday, January 8, 2014 9:01 AM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Preventing 'v
The upgrade table works very nicely for this. Error out on same-version. In my
upgrade table I have:
And in the ui/exec sequence:
SAMEVERSIONDETECTED
And
Dave
>
> From: Tony
>To: General discussion about the WiX toolset.
>
>Sent: Wedn
It is a limitation in FindRelatedProducts that can easily be worked around
using a very simple custom action. The concept is to have a record in the
Upgrade table that will never find any products and then use the custom
action to do a custom detection and place it into the action property
ref
I would also, but it's frequently impossible to make this happen and hard
to defend MSFT's decision to ignore the 4th field.
From: "Rob Mensching"
Sent: Wednesday, January 08, 2014 10:54 AM
To: "General discussion about the WiX toolset."
Subject: Re: [
Personally, I'd update the build to change the build number (3rd field).
-Original Message-
From: Tony [mailto:yellowjacketl...@gmail.com]
Sent: Wednesday, January 8, 2014 8:41 AM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] Preventing 'v1.0.0.1' install when v1.
I was aware of the Windows Installer limitation, unfortunately, our daily
builds do not touch the first three parts of the version, so in our dev
labs we have to "remember" to uninstall first. Most folks know this, but
with several new folks coming onboard and contractors helping here and
there, w
The Windows Installer chooses not to recognize the revision (the fourth build
version) in major upgrades.
-Original Message-
From: Tony [mailto:yellowjacketl...@gmail.com]
Sent: Wednesday, January 8, 2014 7:36 AM
To: WiX Users
Subject: [WiX-users] Preventing 'v1.0.0.1' install when v1.0.
People have successfully chained in NETFX 3.5 on this mailing list. It's more
of a pain thanks to decisions Windows made.
-Original Message-
From: Thomas Due [mailto:t...@scanvaegt.dk]
Sent: Wednesday, January 8, 2014 3:57 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Chain
Try using a Registry Install Constraint:
In 1.0.0.0, add a Version Number Subkey, ie. HKLM\VendorName\Software,
containing String Values Named:
Major Version
Minor Version
Build Number
Etc
Set the values appropriately.
In the upgrade install, test the major version and build number, ie
CONDI
Can someone tell me why patching a uncompressed image requires the attempt
to look for source? I am not prompted asking for credentials, but the
patch log shows it keeps looking for the original install location like
this:
Resolving source.
MSI (s) (9C:30) [08:23:26:466]: User policy value 'Searc
NOTE: This is primarily an issue with our daily dev/interim builds. This
isn't an issue with QA and/or released builds as they have unique
Major.Minor.Build numbers.
I'd like some means to block the install, treat it as an upgrade or even
just a simple pop-up "Do you really want to install anothe
Hi,
I am currently looking into Burn, and have a question. Our application is still
using .NET 3.5, and although we fully intend to update to .NET 4.5, we are not
quite ready for that yet.
It seems that Burn only supports Chaining .NET 4.0 or newer.
Is that correct, or is there a way of chaini
This speaks to the best practice of always setting up your bundles so that they
use the package hashes instead of signatures to validate that the correct
package was retrieved.
> From: dan.mad...@quanser.com
> To: wix-users@lists.sourceforge.net
> Date: Tue, 7 Jan 2014 12:22:13 -0500
> Subject:
24 matches
Mail list logo
