Given that you know the filename already when you create your wxs file, why not
just replace [#fileABCClass] with ABC.class in your wxs file rather than
trying to look it up later on?
If you want to avoid typing the filename all over the place you could use the
preprocessor to set it once.
It would be helpful to know the commands you are using to generate your initial
packages as well as your patches. It sounds like you may be having a problem
because the base path where its looking for the contents of your admin image
doesn't exist. Does this location exist?
Are you saying that you are changing the ComponentRef/@Id in the patch family
and generating a bunch of different patches off of this template? Are you
changing the name if the PatchFamily as well? If so, your patches are probably
superseding eachother. Once you define the contents of a patch
The problem is a mismatch between the PatchBaseline you have in the patch wxs
and the baseline you are specifying to pyro to attach the transform to. The
first argument after the -t is the baseline. If your patch targets RTM (your
patch will apply to an RTM install) then you should have Id=RTM
I can offer a workaround. Add a Property in the same fragment as the update
you want to reference and then reference that property in your patch family.
Alternatively, you can create a patch with no patch families if you are willing
to include all the changes in the product.
This is something
Hi Aaron,
I posted this blog a while back about patching using admin images.
http://blogs.msdn.com/b/pmarcu/archive/2008/05/30/patching-something-you-didnt-build-with-wix-using-wix-.aspx
. I titled it to appeal to people trying to patch things they didn't build
with WiX but it is just as
Can you share your patch authoring as well as the command line arguments you
are using to build the patch. The usual cause for this is a mismatch between
the first argument passed to pyro -t flag and Id in the PatchBasline element in
the patch.
-Peter
My team is hiring. Ask me about the open
I am curious to understand why you were getting unchanged files in your
patches. Wix does a byte by byte comparison of all files before putting them in
a patch. If they don't differ, it shouldn't add them. Perhaps there is a small
bug that should be fixed.
-Peter
My team is hiring. Ask me
You theoretically only need to add it in the upgrade but if you put it in both
that will work before you ship. If you already shipped your product, changing
the target isn't really an option...
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Joseph Valet
Sent: Saturday, November
This should work. Can you file a bug on SourceForge for this?
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Hancock
(HSG)
Sent: Tuesday, November 13, 2007 7:08 AM
To: [EMAIL PROTECTED]; wix-users@lists.sourceforge.net
Subject: [WiX-devs] Bug in Wix preprocessor?
I'm
It compares the files on disk and does a bitwise comparison of the files. If
they are truly identical, it is smart enough to know. The CompareFiles method
is also extensible if you implement a binder extension which would allow you to
incorporate any additional smarts that you can infer based
You don't need to create the cab yourself. WiX will do that for you.
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Lanteigne, Alan
Sent: Thursday, November 08, 2007 9:56 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] New to WIX, trying to use VOTIVE 3.0 but can't get
MSDN topic Preventing a Patch from Requiring Access to the Original
Installation Source.
Phil Wilson
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Peter
Marcu
Sent: Tuesday, November 06, 2007 11:11 AM
To: Schuett, Michael; wix-users
Not possible using the Setup Deployment project. You can however build patches
out of the MSI's it produces using wix v3's admin image patching features.
Generate an admin image of your baseline and upgrade msi's. Call torch with -ax
and the msi's in the admin layouts. Then follow the wix patch
The issue is that those columns in the TextStyle table are not marked as
localizable so the !(loc variable replacement never happens.
Please file a sourceforge bug on this.
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kelly Leahy
Sent: Friday, November 02, 2007 8:51 AM
To:
Change the product code.
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Davut Karabay
Sent: Thursday, November 01, 2007 1:40 PM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] How to prevent cached msi being invoked (not asking
msiexec /fv)
Re: [WiX-users] How to
Karabay [mailto:[EMAIL PROTECTED]
Sent: Thursday, November 01, 2007 2:31 PM
To: Peter Marcu; wix-users@lists.sourceforge.net
Subject: RE: [WiX-users] How to prevent cached msi being invoked (not asking
msiexec /fv)
Hi Peter - What do you mean by changing the product code
ultimate goal is.
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Davut Karabay
Sent: Thursday, November 01, 2007 2:31 PM
To: Peter Marcu; wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] How to prevent cached msi being invoked (not asking
msiexec
For the past few wix builds, we have been having some assembly loading problems
due to mismatched strong names in the wix binaries. This has been resolved and
the latest build should work. http://wix.sourceforge.net/releases/3.0.3429.0/
Are there any differences in the table definition for WixFile between the two
wixouts? Can you send just the tale definitions to me?
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Justin Goshi
Sent: Wednesday, October 31, 2007 10:36 AM
To: wix-users@lists.sourceforge.net
Subject:
Yup, that will do it.
From: Justin Goshi
Sent: Wednesday, October 31, 2007 11:12 AM
To: Peter Marcu; wix-users@lists.sourceforge.net
Subject: RE: Torch error
Yup, there are differences in the table definition for WixFile between the two
wixouts. It's because my base image wixout was generated
Use a preprocessor variable.
$(var.TakeFolder) and on the commandline to candle pass -dTakeFolder=1.
Then change it to 2 when you need to change it to 2.
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jason Rivers
Sent: Monday, October 29, 2007 4:19 AM
To:
and that
process is documented in the latest chm file about the Patch element.
From: Jim Williams [mailto:[EMAIL PROTECTED]
Sent: Monday, October 29, 2007 11:22 AM
To: Peter Marcu; WiX-users@lists.sourceforge.net
Subject: RE: Doing QFEs With WiX
I am a little behind on keeping up with the latest updates
What version of WiX are you using?
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jim Williams
Sent: Monday, October 29, 2007 11:16 AM
To: WiX-users@lists.sourceforge.net
Subject: [WiX-users] Doing QFEs With WiX
We currently have a product which installs, literally, thousands of
In the last couple of months support was added to wix for specifying transform
validation flags for your transforms either on the command line to torch, or
through your patch authoring. These flags determine which products your patch
transforms will apply to.
Adding an upgrade table using a
The wixout is not a pure xml file in WiX 3.0. It has a cab at the beginning of
it that contains embedded binary files.
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Justin Goshi
Sent: Tuesday, October 23, 2007 12:26 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users]
You could use 3 different properties. One for the command line, one for the
registrysearch, and one for the default. Then have two set property custom
actions conditioned on whether or not the command line property is set or if
the registrysearch property is set. If they are, then you would set
WiX 3.0 is fairly stable at this point. Very few new features are being added
and it is being used by some fairly large and complex installs already. It is
also is more feature rich than 2.0, as well as having many bugs fixes that
didn't make it into 2.0. As long as you are willing to update
PROTECTED] On Behalf Of David Stindl
Sent: Tuesday, October 16, 2007 5:38 AM
To: WiX Users
Subject: [WiX-users] Patch element and creation of patch in 3.0
Hallo all,
could you anybody explain me, how to create patch in 3.0 WiX version?
I've read any samples from Peter Marcu (e.g.
http
Hi Doug,
Can you verify for me whether or not the images are removed after a reboot? My
suspicion is that because the file is in use, the OS cant remove it and
schedules a Pending File Rename Operation on the file which will be executed
on a reboot.
If they are not removed on reboot, let me
The transforms in patches usually only apply to a single baseline. In your
case, you chose your RTM as your baseline. A patch can carry multiple
transforms but you will need to include both in the patch if you want your
patch to apply to both scenarios.
The other option is to carry the single
know this isn't quite the answer you were hoping for but at least we know its
not an installer/CA problem. Its in ngen itself and the way it manages its
state.
From: Doug Payne
Sent: Wednesday, October 10, 2007 10:06 AM
To: Peter Marcu; wix-users@lists.sourceforge.net
Subject: RE: NGen
Sorry, no workarounds that I could see.
From: Doug Payne
Sent: Wednesday, October 10, 2007 11:50 AM
To: Peter Marcu; wix-users@lists.sourceforge.net; Sumit Mehrotra
Subject: RE: NGen and uninstalling
Thanks, Peter. This is consistent with what I just discovered. I paused setup
just after my
be able to track when the bug gets fixed.
From: Cristian N. Baiu [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 03, 2007 8:19 PM
To: Peter Marcu
Cc: wix-users@lists.sourceforge.net
Subject: Fw: [WiX-users] Fw: Some STUPID Limitations in WiX
Hello Peter,
Thanks again for your answers. Melt
Tallow doesn't exist in WiX 3.0. Take a look at Heat.
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sergei Shelukhin
Sent: Tuesday, October 02, 2007 8:36 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] no tallow in wix 3.0
Hi. How come there's no tallow utility in
You should be able to pass transforms generated from wixpdb's in combination
with ones generated from admin images. You will need a transform passed to
torch for each product you want to target because product code information is
important and I assume each language you ship has a different
I meant pyro when I said torch below.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Peter Marcu
Sent: Tuesday, October 02, 2007 10:15 AM
To: Bob Arnson; Cristian Baiu
Cc: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Fw: Some STUPID
. Baiu [mailto:[EMAIL PROTECTED]
Sent: Tuesday, October 02, 2007 11:18 AM
To: Peter Marcu; [EMAIL PROTECTED]; Cristian Baiu
Cc: wix-users@lists.sourceforge.net
Subject: Fw: [WiX-users] Fw: Some STUPID Limitations in WiX
Thanks Bob, thanks Peter for your answers.
I will not have problems
Apparently wix.dll was strong named with a different public key this time
around while all the other tools are using the correct one. We are looking what
caused the problem and will get a fix and release a new build once its fixed.
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
The error is saying that the DllPath column of the ComPlusAssembly table has a
value of LAPComPlusAssembly. This is a foreign key and therefore needs to be
present in the table has the corresponding primary key. Make sure that
LAPComPlusAssembly is defined as a Primary key somewhere else in
If you need to get an msm from someone because they don't use WiX, that makes
sense. If you're msi is the only one consuming those msm's you wont hit the
major problem of servicing msm's which is, you don't know all of the various
places it was consumed and therefore you don't know all the
For #1. FileSearch, RegistrySearch, and DirectorySearch search are part of core
Windows Installer functionality. This is why WiX has those contructs in the
language and not the others.
For #2. Use libraries instead of modules. My advice is to produce modules only
if you are shipping them for
On your Media element add a cabinet attribute and an EmbedCab='yes' attribute.
That should do it.
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jessi Darling
Sent: Tuesday, September 25, 2007 2:08 PM
To: wix-users
Subject: [WiX-users] Deploying the MSI
Is there a way that I can
No. If you want to install the contents of multiple msi's you will need a
chainer/bootstrapper.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of shambhu kumar
Sent: Sunday, September 16, 2007 8:58 PM
To: wix-users@lists.sourceforge.net
Subject:
It will fail with error code 1618 Another installation is already in progress.
Complete that installation before proceeding with this install.
Why do you need to run the msi nested? Could you run one msi and then the other?
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dix,
When no keypath is specified, it uses the first resource in the component. In
your case it was the first file. In order to remove that file you need to
remove the entire component. Note, that if you remove a component, you have to
remove the entire feature. Removing a keypath file using a patch
My recommendation would be to either put this authoring as a child of your
Product element or use a wxi (wix include) to pull it in from an external
file.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chris Tavares
Sent: Tuesday, August 07, 2007 1:35
I don't think the preprocessor supports dots in the name of the variable. Try
replacing them with underscores or something and see how that goes.
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Hall
Sent: Friday, July 27, 2007 12:58 AM
To:
Unfortunately, removing a file via a patch is not as easy as that. Windows
Installer requires that if a component is removed, the feature containing it be
removed so you probably don't want to do that. You need to author a RemoveFile
element to remove the file in your component. This will
You should also note that when doing patches, you need to add a removefile
entry in order to remove files. For update/add you must update the keypath file
of a component in order to see changes in the component during patching.
Ideally, when adding new files, they are in their own component. Is
The fix for this was submitted yesterday and should in the next published build.
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mike Dimmick
Sent: Tuesday, June 05, 2007 1:06 PM
To: 'koawmfot'; wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] problem with serviceconfig
to error whenever it encounters a FragmentRef.
Peter Marcu
Software Development Engineer
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions
52 matches
Mail list logo
