Hi,
What I need to do is get the product version (major/minor/build/release from a
file during a custom action.
I could write this, but wondered whether this is already included.
Cheers
Sean.
-Original Message-
From: Rob Mensching [mailto:r...@robmensching.com]
Sent: 23 July 2013 04:40
T
Always better to start with what you are trying to accomplish rather than
ask a very narrow question with no context.
On Mon, Jul 22, 2013 at 3:18 PM, Sean Farrow
wrote:
> Hi,
> I'm just in the process of writing a custom action, I know file version
> functions are in fileutil.cpp/h. Are Product
dark.exe can extract the files. This error has been intermittent. If you
have a consistent repro, it would be awesome if you could use Process
Monitor to capture everything going on through the failure. Then put the
.pml file and the corresponding burn.log somewhere and I'd like to take a
look.
O
Hi,
I'm just in the process of writing a custom action, I know file version
functions are in fileutil.cpp/h. Are Product version functions surfaced by WiX
dutil?
Regards
Sean.
--
See everything from the browser to the dat
Okay tried a few thing suggested in to following web page, but still no go...
Still same 0x80004005 error on extraction of files.
Is there a command line that we can call to manually extract all files
within the Burn bootstrapper .exe so that we can verify that the files are
actually in the .exe f
Ordered! Thanks for the tip - physical reference manuals are not
usually my first thought when it comes to up-to-date documentation
On 7/22/2013 4:43 AM, John Ludlow wrote:
> Agreed, that's really the only complete reference source for WiX 3.6, and
> there's quite a lot that you can only really
I am trying to get Burn (bootstrapper) to show in different languages and
need a bit of help with this.
I saw an article that mentions that WiX Burn fully supports translations,
but then I read further that it only shows in English???
So what I would like to know is if there is built in language
Classification: Public
I totally agree :)
-Original Message-
From: John Cooper [mailto:jocoo...@jackhenry.com]
Sent: July-22-13 2:13 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] passing command args to MSI from bundle [P]
It's redundant and probabl
It's redundant and probably a significant source of the problem. It should be
removed or at least commented out so he knows which bootstrapper he's actually
debugging.
--
John Merryweather Cooper
Build & Install Engineer - ESA
Jack Henry & Associates, Inc.®
Shawnee Mission, KS 66227
Office: 9
I assume that the organization of the setup is already determined because
it's a migration, right? Some of things you may need to look at are:
1. Organization of the parts of the setup into functional units - features,
and from that the components in those features. The terms "feature" and
"compon
Classification: Public
Then what is the purpose of using MSBuild + WIX bundle + WIX MSI that seems
like an overkill?
-Original Message-
From: John Cooper [mailto:jocoo...@jackhenry.com]
Sent: July-22-13 12:50 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-u
As an after build task, I'm doing a GeneratorBootstrapper command. Perhaps that
clobbers any custom stuff I have in my Bundle.wxs for the MSI?
Mark Freedman
-Original Message-
From: Freedman, Mark P. [mailto:mark.freed...@jhuapl.edu]
Sent: Monday, July 22, 2013 11:08 AM
To:
Steve,
Correct, I do not see the logs.
I experimented with removing my GenerateBootstrapper task as I mentioned
before, reproduced below. I then see the log file show up, and I see similar
log files as you have described, and the variable SETLOCALDB set to 'true' as
you would expect. The probl
I'm really at a loss as to why I'm seeing this behavior. Only if I manually run
setup.exe on the command line with my parameter, as in your example, do I see
it be able to be picked up by the MSI.
In your email below, I see that you just have some hardcoded values, which is
really what I want.
Classification: Public
The log files from the bundle are placed in %temp% are i.e.:
Weird, try taking out the Persisted=yes out of the variable element in your
bundle.wxs
Btw what version of WIX are you using?
My bundle log shows this:
[2364:27B0][2013-07-22T11:21:45]i001: Burn v3.7.1224.0, W
Well, if the bootstrapper has the same name as the Burn executable, there's an
even chance the build of Burn will be suppressed on your build server.
--
John Merryweather Cooper
Build & Install Engineer - ESA
Jack Henry & Associates, Inc.®
Shawnee Mission, KS 66227
Office: 913-341-3434 x791011
Steven,
GenerateBootstraper I belive is an MSBuild task. It lets me piggy back off of
the bootstrapper logic that is in your SDK folder, used by Visual Studio
Setup/Deployment projects, e.g.:
C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bootstrapper
I'm doing this method as to not repea
Steven,
I see what you're doing and it all makes sense.
I can't find any logs files where you describe, or any log files that include
my bundle name. I do see an install.log, but doesn't mention the defaulted
MsiProperty I'm trying to set, nor does it have the date/time stamps like the
excerpt
Old MsBuild/Visual Studio task that takes a manifest, a set of dependencies
usually embedded in the project file, and builds a primitive bootstrapper. We
used to use it before they hired me.
--
John Merryweather Cooper
Build & Install Engineer - ESA
Jack Henry & Associates, Inc.®
Shawnee Missio
Classification: Public
If you run your bootstrapper exe (burn.wxs) then through it run the MSI, you
don't see any log files in your %temp% folder?
-Original Message-
From: Freedman, Mark P. [mailto:mark.freed...@jhuapl.edu]
Sent: July-22-13 11:49 AM
To: General discussion for Windows Inst
Classification: Public
I am totally confused now, are you using MSBuild to create a setup.exe that
kicks off your installer?
The point of the WIX Bootstrapper (bundle.wxs) is to create an executable that
allows you to install any pre requisites you have (exe/msi/msu) and of course
kick off your
Classification: Public
Do you want your SETLOCALDB default value to be true or false?
In your bundle.wxs you have it set to true, in your product.wxs you have it set
to false Have the default value set in the bundle.wxs and get rid of the value=
in your product.wxs...
-Original Message-
I've removed the default value in product.wxs, but to no avail. That's why my
custom action reports the property as being null.
I'm assuming that the bundle log is the install.log I see by default in my temp
directory in a VSD.tmp directory. It has no mention of the variable when
simply run
Classification: Public
Sorry Mark,
I am not familiar with Generatebootstrapper what is that?
Steve
-Original Message-
From: Freedman, Mark P. [mailto:mark.freed...@jhuapl.edu]
Sent: July-22-13 12:15 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] pas
The bundle and installer logs would tell the story... Start with the bundle
log and ensure it is passing the default value to the MSI, then inspect the MSI
log file to find where the property is changing.
-Original Message-
From: Freedman, Mark P. [mailto:mark.freed...@jhuapl.edu]
Sent
Bill, did you ever get this working?
I have seen some other posts on this and some of the answers seem to suggest
that the issue is that the bundle is not signed correctly.
All our Chained MSI packages are signed as well as the bundle and we are
still getting these errors.
In my original testing
Classification: Public
Nope the property I have is a made up property that I use... in the bundle.wxs
I set the default value to WARN which is passed onto the MSI and my custom
action uses it.
I can change the value via the command line i.e.: MYBootstrapper.exe
SERVICESLOGLEVEL=DEBUG which would
Thanks Steven,
I tried that as well, not defaulting the value in the Product.wxs and it seems
that when the MSI takes over, the value of the property is empty string or
null. If I do call my setup.exe via commandline, I am able to set it and it
picks it up in the MSI. Is your MSI Property in t
Classification: Public
Take out the Value out of your Product.wxs i.e.:
Set the default value of the property in the bundle.wxs so it is passed on to
the MSI, that way you have the default value but you can change it via the
command line to change it...
-Original Message-
From: Freedma
Users will have no way to uninstall burn package AFAIK. See
http://www.joyofsetup.com/2013/07/05/burn-zero-one-or-n/ .
Wes
-Original Message-
From: Tomas Köhn [mailto:tomas.k...@cellavision.se]
Sent: July-22-13 8:20 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] [wix-users
It seems that if I run setup.exe via the commandline, the MSI Property does get
forwarded to the MSI, e.g.
Setup.exe SETLOCALDB=true
Mark Freedman
-Original Message-
From: Freedman, Mark P. [mailto:mark.freed...@jhuapl.edu]
Sent: Monday, July 22, 2013 8:06 AM
To: General discussion for
I've tried Steven's method of defining a variable and assigning it to the
MsiProperty, as well not using a burn variable and just using the MSI Property
with a constant. When I have the Property defined in my product.wxs, it is
always set to the defaulted value set in the product.wxs. The value
Agreed, that's really the only complete reference source for WiX 3.6, and
there's quite a lot that you can only really learn via the book. Be careful
though as I saw a bogus addition flying around on Amazon UK (it's gone now
so maybe it was just a mistake).
In the book, your requirements above mea
Ok, minor facepalm moment here.
It turned out that my component library project had a reference to my
action library from when I was testing the action out before turning it
into an extension. When this was combined with the reference created from
the code, this created two references to the same
We need to support installation from both .exe and .msi (for remote program
distribution). As I understand, burn can't be used without installing into ARP.
We want the program installation to be the same from both .exe and .msi.
If I set DisableModify="yes" DisableRemove="yes", the bundle (burn)
I would encourage you to purchase this book -
http://www.amazon.com/WiX-3-6-Developers-Windows-Installer/dp/1782160426/ref=sr_1_1?ie=UTF8&qid=1374490843&sr=8-1&keywords=wix
WiX 3.6: A Developer's Guide to Windows Installer XML [Paperback]
Nick Ramirez
Be sure to get the latest ed
Hey List!
I've just begun the exciting journey of migrating our company's
installer from a large, slow NSIS script to a shiny new WiX project, and
I was hoping the list could point me towards a few more or let me know
about any pitfalls I may encounter. I've done some research & found a
few
37 matches
Mail list logo
