John,
*sigh* I would like to use 3.9 but things move slowly here...
Thanks for the help!
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/burn-error-0x800b0100-help-tp7599876p7599881.html
Sent from the wix-users mailing list archive at Nabble.com.
Ext: 431050
|jocoo...@jackhenry.com
-Original Message-
From: victorwhiskey [mailto:victorhwhis...@yahoo.com]
Sent: Thursday, April 9, 2015 11:36 AM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] burn error 0x800b0100 help
John,
I'm using wix 3.6/3.8.
What ex
John,
I'm using wix 3.6/3.8.
What exactly is the problem? Is it the MSI is not signed? How do I use the
other way, hash verification?
Thanks!
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/burn-error-0x800b0100-help-tp7599876p7599879.html
Sent
nc.® | Lenexa, KS 66214 | Ext: 431050
|jocoo...@jackhenry.com
-Original Message-
From: victorwhiskey [mailto:victorhwhis...@yahoo.com]
Sent: Thursday, April 9, 2015 10:52 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] burn error 0x800b0100 help
Hello all,
I haven't
Hello all,
I haven't had much luck with responses with my last few questions.
Hopefully, I can get some help on this one.
I have a project that which uses burn and the msi and burn are both in
working order. Now I have to add an install of a certificate to the machine
into the certstore. So I use
ay with WiX for doing
this installation.Thanks for any support.
> Date: Sat, 3 Jan 2015 10:21:43 -0700
> From: nickra...@hotmail.com
> To: wix-users@lists.sourceforge.net
> Subject: Re: [WiX-users] Burn error with document folder on network location
> (works fine running only th
Okay, so it sounds like you want to:
1. Install the file to the Documents folder
2. Edit the file in place after it's been installed
I've often seen people posting about having problems using XmlFile. I have
always used the XmlConfig element instead and haven't had any problems. You
might get les
ll 7)
Any Suggestion, about hot to proceed, or what I could try?
> Date: Sat, 3 Jan 2015 09:23:02 -0700
> From: nickra...@hotmail.com
> To: wix-users@lists.sourceforge.net
> Subject: Re: [WiX-users] Burn error with document folder on network location
> (works fine running only th
/1) First try - I have installed the file on the Document's folder and the
modified it with the wix extension XmlFile.this work for coping the file but
fail to modify it as reported the error that it can't find the file to
modify/
Some questions I have:
1. What error are you seeing?
2. What are y
I need to copy an xml file on the User Document's folder and I need to change
some attribute of the elements inside the xml file based on user choices during
setup.If the user has the document's folder located on a network path the setup
fail as it can't locate the location.
I have made this ins
Defect added: http://wixtoolset.org/issues/4443/
On Mon, Jun 9, 2014 at 4:27 PM, Ed wrote:
> I see, thanks for the help!
>
> Our team has been filling that fourth index with larger numbers for years
> with no ill affects, so I assumed this was acceptable. I will deliver to
> them the bad news ;
I see, thanks for the help!
Our team has been filling that fourth index with larger numbers for years
with no ill affects, so I assumed this was acceptable. I will deliver to
them the bad news ;)
I will also open a bug for wix to flag such builds with compile warnings so
other teams don't encount
On 6/9/2014 6:51 PM, Ed wrote:
> I understand the build version must be less than 65536, but I believe that
> refers to the third index in the version number.
Product versions must be less than or equal to 255.255.65535.65535.
http://msdn.microsoft.com/en-us/library/aa370859%28v=vs.85%29.aspx make
concerning 'Invalid product version '{0}'. Product version must have a
major version
less than 256, a minor version less than 256, and a build version less
than 65536.' I believe the version format is Major.Minor.Build.Revision,
hence the compile error is correct, albeit missing any limit informati
Thank you Bob,
I have isolated the issue by using basic Visual Studio WiX projects (Setup
Project and Bootstrapper Project)
To create the MSI, I created a simple Setup Project and changed the
Product's Version attribute to 1.0.0.65536. Then I crated a basic
Bootstrapper Project and added a single
My Mistake, it's the MSI causing the issue, not the Burn Engine. See
the post I linked earlier...
Quoting Bob Arnson :
> On 6/9/2014 6:01 PM, Carter Young wrote:
>> Your getting the error because the number is ignored all together,
>> regardless of type, int long string doesnt matter... its un
On 6/9/2014 6:01 PM, Carter Young wrote:
> Your getting the error because the number is ignored all together,
> regardless of type, int long string doesnt matter... its unable to
> parse because there is no underlying code in burn that says parse 4th
> digit
Burn supports all four places of version
On 6/9/2014 5:32 PM, Ed wrote:
> Wix is allowing me to create msi files with a large number in the fourth
> version index (6-digit numbers, i.e. 11).
How are you authoring that? If you put such a version as a literal
string, the compiler will fail with an error message saying you can't do
tha
See this post:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Setup-upgrade-needs-to-care-for-4th-part-of-version-number-td3250189.html
Carter
Quoting Ed :
> Sorry I'm still a bit confused. If this is the case, then why am I able to
> create a bootstrapper which bundles an MSI fi
Sorry I'm still a bit confused. If this is the case, then why am I able to
create a bootstrapper which bundles an MSI file that has a fourth index
version number of 65535?
The fact that an MSI with fourth index 65535 (1.0.0.65535) will execute
from a WiX bootstrapper with no issue, while an MSI fi
Your getting the error because the number is ignored all together,
regardless of type, int long string doesnt matter... its unable to
parse because there is no underlying code in burn that says parse 4th
digit
Quoting Ed :
> We are okay with WiX ignoring this number for upgrading purposes.
We are okay with WiX ignoring this number for upgrading purposes. We simply
attach the build CL in the 4th index so we can trace each MSI back to the
point of creation if needed
The problem seems to be that Burn can't parse MSI files which fill this
value with a number larger than 16-bit unsigned.
This is expected behavior because all of WiX ignores the 4th version
number... If you want to test for it, you must do it manually.
Carter
Quoting Ed :
> Wix is allowing me to create msi files with a large number in the fourth
> version index (6-digit numbers, i.e. 11).
>
> I'm trying to u
Wix is allowing me to create msi files with a large number in the fourth
version index (6-digit numbers, i.e. 11).
I'm trying to use burn to create a bootstrapper which bundles my wix
installer. When I include an msi in the bundle which has a fourth version
index greater than 65535 (16-bit uns
application again.
-Original Message-
From: Kelly Graus [mailto:kelly.gr...@toltech.net]
Sent: Wednesday, October 10, 2012 1:47 PM
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] Burn Error
Hello,
I have a customer who is receiving error 0x80070660 when running a
neral discussion for Windows Installer XML toolset.
Subject: [WiX-users] Burn Error
Hello,
I have a customer who is receiving error 0x80070660 when running a Burn based
installer on Windows Server 2008 R2. Below is the log file. I have verified
that both the temp directory (pointed to from the TMP
Hello,
I have a customer who is receiving error 0x80070660 when running a Burn based
installer on Windows Server 2008 R2. Below is the log file. I have verified
that both the temp directory (pointed to from the TMP and TEMP environment
variables) and the c:\ProgramData directory are writable
I got around this for now by removing the certificate, as described here:
http://www.curlybrace.com/words/2008/09/12/stripping-an-authenticode-signature/
From: Dan Puza
Sent: Thursday, June 16, 2011 4:04 PM
To: 'wix-users@lists.sourceforge.net'
Subject: Burn - Error 0x80096010: Failed authentico
Is it possible to instruct Burn not to verify the signature of an ExePackage?
The EXE file is published by a third party, and can't be modified. Is it
really just not possible to use it in my bootstrapper since there is a problem
with the signature?
I am very new to Burn, so it could be that
29 matches
Mail list logo