I have a setup project in which I have file called ProjectManifest.wxs
which contains a Fragment declaring a PackageGroup for my MsiPackage and
also sets up some registry searches for some prerequisites for my msi.
I also have a bootstrapper project that uses this ProjectManifest.wxs
file so
I used to use a wixlib project but when I added multiplatform projects and
tried to use MSBuild directly for my build process I had problems with a x64
project failing due to a dependency on the wixlib project (which had already
been built) but would not build with platform set to x64.
So for
You can also do this by right clicking on the project and Add -- Existing
Item..
When you find the file you want, don't double click, go down to the Add button
and you will notice a tiny arrow to the right, click and then select Add As
Link.
That should do it, and eliminates having to modify
Hey Bob,
It might be a case of The Mondays but I'm at a loss at what you are getting
at :( What are these other files that might get output by torch? How can I
supress their output?
No typo in this email! ;)
-Original Message-
From: Bob Arnson [mailto:b...@joyofsetup.com]
Sent:
Hi Bob;
Thanks a lot for the insight. I stared at that and did not pick up on the
line feed which had broke the Product/@Version entry.
Thanks;
Phill
--
View this message in context:
I've gone for the Add as Link approach which has done the trick
nicely.
Thanks everyone.
David
-Original Message-
From: Tunney, Stephen [mailto:stephen.tun...@nuance.com]
Sent: 09 June 2014 14:09
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] Is it possible to
I am using WIX Burn to create the bootstrapper. The payload Chain contains an
MSI MyMSIPackage. The MSI have embedded transforms for some 5 different
languages. The bootstrapper is able to install and uninstall the MSI in
english environment properly. But when I execute it in non-english OS it
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
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
Recently we've updated from registering COM objects with .NET 3.5 to
registering COM objects with .NET 4.0; however, they seem to not be behaving
properly anymore (windows which are supposed to be docked are now floating). Is
there something different which must be done for registering COM
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
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 ecarp...@gmail.com:
Wix is allowing me to create msi files with a large number in the fourth
version index (6-digit numbers, i.e. 11).
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
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 ecarp...@gmail.com:
We are okay with WiX ignoring this number for
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
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] Upgrading...
I do
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 ecarp...@gmail.com:
Sorry I'm still a bit confused. If this is the case, then why am I able to
create a bootstrapper which
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
On 6/9/2014 9:06 AM, Tunney, Stephen wrote:
It might be a case of The Mondays but I'm at a loss at what you are getting
at :( What are these other files that might get output by torch? How can I
supress their output?
Rename the .wixmst to .cab and open it in explorer. You'll see binaries
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
My Mistake, it's the MSI causing the issue, not the Burn Engine. See
the post I linked earlier...
Quoting Bob Arnson b...@joyofsetup.com:
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
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
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
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 makes
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
Defect added: http://wixtoolset.org/issues/4443/
On Mon, Jun 9, 2014 at 4:27 PM, Ed ecarp...@gmail.com 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
OK. That's kinda cool, now how do I stop it from outputting that? :)
From: Bob Arnson [b...@joyofsetup.com]
Sent: June 9, 2014 6:24 PM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Bug in torch - wixmst output is not in XML format
On
Hi,
Using Wix we can able to create Application Virtual Directory.But,know
i need to update the application
--
Thanks Regards,
Chaitanya.
--
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
28 matches
Mail list logo
