Hi,
First of, let me try to explain what I am trying to accomplish. Our
application
uses a very big library that needs to be installed. This is a third
party library
and doesn't get updated a lot. I want to speed up the build of our installer
by somehow prepackaging the library once.
I already
Very typical to come up with some ideas myself just after I press send...
Here are two ideas that popped into my head:
1) Build an installer without the library, than use a transform to add
the missing functionality.
2) This is a bit more of a hacky way:
- build a binary wixlib
-
Actually, no. Say I have two wixlibs for two different features. I run
heat as a prebuild on both libs (so in total it is run twice) with the
-cg option which very nicely generates componentgroups, but the ID's for
each directory are things like 'folder1'. Now when both libraries have
directories
I have been following this thread (as it has a definite impact on what I am
working on).
Searching through the online MSDN docs, I came across the following that
describes Per Machine/Per User installs and the impact of the ALLUSERS
variable. It has also been updated with the Windows 7 details.
Hi WIX users,
I have to do a patch for a major upgrade. I haven't done that yet and
trying to find a good resource that will show me how to. I have been
using the three links below for information, but they seem to be doing
different things. Can anyone steer me towards a good recent how to
Not to flog a dead horse or anything, but consider this scenario
I create my single installer package. Inside I provide two different
features:
- Feature 1: All Users (Per Machine) install, will required elevation
- Feature 2: Per User install, can be installed by any standard user or
better.
We are using Wix to install our (Java) application. Updating works fine,
even launched application (and service) are handled gracefully.
For providing users who report bugs a very quick bug-fix build we offer a
plain zip file containing just the replaced few binary (.jar) files which
they can
Just what I say: IDs should be GUIDs. If actually is not, it is a bug, since
you run in the problem that you actually run into. If I were you, I would
file a bug report describing the problem.
Regards
Markus
-Original Message-
From: Nick Ball [mailto:nick.b...@grantadesign.com]
Sent:
This isn't a WiX problem. It's MSI, and there's nothing you can really do
about it in the setup authoring, as far as I know. The only way I'm aware
of to change it is to use MSIEXEC command line parameters to tell MSI to
overwrite changed files.
You should really look into using patches or
But how to do that, author the package based on your decision?
I mean, I just have two files, one program menu item and one extension verb.
The .wxs file is more or less a copy of the WiX manual's samples / WiX
tutorial code snippets.
The WiX manual does not say something about authoring the
Take a look at the RemoveFile element. It will get rid of existing
files before the new files are copied in to place. Might help in this
situation.
Chad
-Original Message-
From: Thomas Singer [mailto:w...@regnis.de]
Sent: Wednesday, November 04, 2009 10:13 AM
To:
I disagree that structure and content are different concerns, they are the
same (or do you separate files and folders on your harddisk, too?). The
question was, why it is used in the *most simple* examples. Since it does
*not* focus on the example at hand, but instead, makes that examples overly
Hi,
I am using managed customaction.dll. The build infrastructure spins a native
wrapper customaction.CA.dll without a PDB file.
Can I get a PDB file for CustomAction.CA.dll by changing the build process?
Thanks
Lian
Did you already try the -cc and -reusecab switches for light? Make sure to
specify both switches at the same time, and a valid folder after the -cc
option. This should allow light to just use an existing cab if none of the
files in that cab have changed. Then let it be a cab external to the MSI
It's important to keep in mind the DTF (for the most part) provides a managed
interop around the windows installer APIs. You'll still need to become
intimately familiar with [
http://msdn.microsoft.com/en-us/library/aa368786(VS.85).aspx ] and how to
handle all the messages and compute the
Hi Markus,
I've been writing WiX installers for over a year now and started off
relatively soon with using DirectoryRef/, putting solely my directory tree
in one WXS (DirectoryStructure.wxs) and then having each File/ referencing
the directory ID's in that file.
This later became very valuable
The PDB for the unmanaged CA wrapper is always sfxca.pdb, regardless of what
your managed custom action code is. Sfxca.pdb is included in wix3-pdbs.zip
published with every build. If you like, you could add a postbuild step to copy
and rename sfxca.pdb to YourCustomAction.CA.pdb.
-Original
Spent one hour, finally discovered my own fault: I wrote light x.wixlib
y.wixOBJ instead of light x.wixlib y.wixLIB -- certainly there will be no
resources found in the original .wixOBJ, but only in the .wixLIB...! :-(
-Original Message-
From: Markus Karg [mailto:markus.k...@gmx.net]
I understand *your* reasons, but again, my question was: Why using
DirectoryRef in the *most simple*, *very first* How-To (that
HelloWorld-style one read first by every WiX beginner) printed in the WiX
documentation? My question is *not* if anybody knows *any* reason for using
DirectoryRef in
When I add a User element inside my installers component, as such, I receive a
Fatal Error during uninstall, even if I do not use the user within the install.
Component Id='component_Service' Guid=4ADD096A-CF39-454b-AF01-1EA39092C9DB
DiskId='1'
util:User Id ='appServiceAccount'
The only entry I see related to this error is the _SummaryInformation table's
(from the Diff.wixmst) field '11'. Here's the corresponding row entry for that.
row op=add sectionId=/ sourceLineNumber=d:\Enlistments\
In addition, this also fails to uninstall.
util:Group Id=IISAppPoolGroup Name=IIS_WPG/
Component Id='component_AppPoolUser'
Guid='C797149D-77AC-4cb1-A3B0-C2C5DA79385D'
util:User Id ='appPoolAccount' Name='[XPJUSER]'
Password='[XPJPASSWORD]' Domain='[XPJDOMAIN]'
Regarding an alternative to admin installations:
If you aren't trying to patch merge module contents, you could try using the
wixpdb files instead of the admin images.
If your original wixpdb doesn't have access to the older binaries, you can
do the following in order to force a bound/binary
Assuming that PIDKEY is just a property you're setting, you'll
probably want to set the property to a default value (e.g. DEMO) and
do a RegistrySearch to overwrite it if you can find an existing PIDKEY
in the registry.
Property Id=PIDKEY Admin=yes Secure=yes Value=DEMO
RegistrySearch
Correct, it's all due to the compression algorithm :)
We use mszip for internal beta builds, high for MSI-only releases
for corporate customers (as well as for the 1Mb bootstrap EXE that
later downloads an MSI payload), and finally an LZMA self-extracting
EXE containing an MSI with compression
John H. Bergman (XPedient Technologies) wrote:
How do I determine the cause of the uninstall failure?
Verbose log. See
http://www.joyofsetup.com/2008/07/15/verbose-logging-from-wcautil/ to
get verbose logging from WiX custom actions.
--
sig://boB
http://joyofsetup.com/
Markus Karg wrote:
I understand *your* reasons, but again, my question was: Why using
DirectoryRef in the *most simple*, *very first* How-To (that
HelloWorld-style one read first by every WiX beginner) printed in the WiX
documentation?
All other things being equal, prefer best practices.
--
Ali Khan wrote:
I need to edit one of WiX's standard .IBD file (bitmap) and can't seem to
find an appropriate editor.
WiX doesn't use .ibd files, just .bmp bitmaps.
--
sig://boB
http://joyofsetup.com/
--
Let
Dan Giambalvo wrote:
I'm running into a strange issue with an interaction between an Edit control
and a default button with a custom action on a WiX Dialog. The Edit is tied
to an MSI property, and the button's custom action does some processing to
validate the value of that property.
Sharat: I am a little confused as to what exactly you are trying to achieve.
If you already have an MSP (SP1_Patch.msp), I think the diff between
Release.MSI and (Release.MSI + SP1_Patch.msp) would be exactly SP1_Patch.msp,
thus you don't need to do anything. What am I missing?
Svet
30 matches
Mail list logo
