Ok, that's really weird. That's not what I see at all.
ExitCodeInfo.cs:38:this.Code = value.ToString();
I'm looking at wix38rtm.
Does WiX 3.8.1128.0 not correspond to wix38rtm?
--
Edwin G. Castro
-Original Message-
From: Rob Mensching [mailto:r...@firegiant.com]
Sent:
Ok, that's really weird. That's not what I see at all.
ExitCodeInfo.cs:38:this.Code = value.ToString();
I'm looking at wix38rtm.
Does WiX 3.8.1128.0 not correspond to wix38rtm?
On Thu, Jul 2, 2015 at 5:18 PM, Rob Mensching wrote:
> ExitCodeInfo.cs:38:this
ExitCodeInfo.cs:38:this.Code =
unchecked((uint)value).ToString();
_
Short replies here. Complete answers over there: http://www.firegiant.com/
-Original Message-
From: Edwin Castro [mailto:egca...@gmail.com]
Se
Our bundle fails to install when our product is built with bullseye for
code coverage. The bundle log is not created. Instead
Setup_timestamp_Failed.txt is created and contains the following:
[04AC:0744][2015-07-02T14:59:01]e000: Error 0x80070057: Failed to
parse @Code value: -1
[04AC:0744][2015-0
I forgot to mention that I'm using WiX 3.8.1128.0.
On Thu, Jul 2, 2015 at 5:07 PM, Edwin Castro wrote:
> Our bundle fails to install when our product is built with bullseye for
> code coverage. The bundle log is not created. Instead
> Setup_timestamp_Failed.txt is created and contains the follow
Thanks Jacob,
Here is what I now have, in case it is helpful to someone else. I wasn’t able
to find an UpgradeCode, so I’m using the ProductCode. It seems to work fine
with x86 as best as I can understand the logs (haven’t verified 64-bit yet):
In the Bundle element:
1. Strange, though on a version I would compare it to a very.x.y.z
2. My way is the old way, and will fail if the product has been patched.
Upgrade code should be more reliable.
3. Poke around from
http://blogs.msdn.com/b/astebner/archive/2007/01/16/mailbag-how-to-detect-the-presence-of-the-vc-
Dear WiX Support,
I've been trying to add a text file to an MSI package to be used by a custom
action, but without success. I have added two files to the Binary table as
shown below.
At install runtime, I saw only CustomAction1.dll in the WiX temp folder
(example: C:\Windows\Installer\MSI5F
oops -
3. “this site” is
https://allthingsconfigmgr.wordpress.com/2013/12/17/visual-c-redistributables-made-simple/
4. “this post” is
http://stackoverflow.com/questions/23832713/how-to-check-that-visual-c-2013-redistributable-is-already-installed-using-wix
On Jul 2, 2015, at 1:46 PM, David Bur
Thanks Jacob,
Btw, I’m using WiX 3.9 R2, hoping to go to 3.10 when it is stable.
Your solution appears to work, but I have 4 questions about it:
1. The log is strange when I upgrade. I installed version 1.1.4 of my app,
then built version 1.1.5, and installed it. In the log for the upgrade, t
Yeah, okay then. Resetting the ACLs on lots and lots of files can take lots and
lots of time.
_
Short replies here. Complete answers over there: http://www.firegiant.com/
-Original Message-
From: thomas.deboben@rohde-schwa
Hi Rob,
on one system yes 1.3 million files so the installer run 40 min. After
removing these files the installer performed fine again.
On the other system where I added the trace infos onle 215 files with
55MB.
Cheers,
Thomas
Von:Rob Mensching
An: General discussion about the WiX
Lots of files in the folder?
_
Short replies here. Complete answers over there: http://www.firegiant.com/
-Original Message-
From: thomas.deboben@rohde-schwarz.com
[mailto:thomas.deboben@rohde-schwarz.com]
Sent: Thurs
Hi,
no one there who could give me a hint?
Best regards,
Thomas
-Original Message-
[WiX-users] ExecSecureObjects action need very long time
From: Thomas.D - 2015-06-17 12:26:11
Hi all,
I'm having a time problem with my installer.
On some systems (not all) the installer need very lon
14 matches
Mail list logo
