Simplifying the WiX v3 language
Two recent changes that simplify the WiX language will be available in the next weekly release of WiX v3. The goal of both changes is to make simple setup authoring simpler and help reduce redundancy.
Assigning components to features via attribute
The Component element now has a Feature attribute; when set, that component is parented to the specified feature. So the following snippets are equivalent:
<Component Id=”FooComp” Feature=”BarFeature” … />
and
<Component Id=”FooComp” … />
…
<FeatureRef Id=”BarFeature”>
<ComponentRef Id=”FooComp” />
</FeatureRef>
Component/@Feature supports one feature reference. You can still parent one component to multiple features using Feature or FeatureRef and ComponentRef. This change is to simplify the more common case of one component parented to one feature.
Default File Id and Name from Source
Typical File element authoring has several attributes with similar values. A File’s Id, Name, and Source elements might all mention the same file name, for example. WiX v3 already has several defaults that simplify File element authoring, like defaulting the Name attribute value to that of the Id attribute.
The File element now takes the default for the Id attribute from the file name portion of the Source attribute. The Name attribute then gets its default value from Id, so authoring a File element can now be as simple as:
<File Source=”$(env.Bits)\foo\bar\baz.exe” />
The equivalent would be:
<File Id=”baz.exe” Name=”baz.exe” Source=”$(env.Bits)\foo\bar\baz.exe” />
Simple change, simple benefit
The code changes for these two features were trivial. But I think they represent the kind of schema changes you’re likely to see as we head to a WiX v3 stabilization, as Rob mentioned earlier this year. A simpler language makes it easier for designers to generate clean code and for those who prefer hand authoring to minimize unnecessary typing.
December 28th, 2007 at 02:54 #Carl
Great changes!
A few more things you could do to make a WiX user’s life simpler:
* Some way of telling WiX that a assembly has to go on disk as well as in the gac without having to add a new folder and a separate file entry. Maybe a GACOnly attribute that could be set to no by default? I suppose we would still have to put the file elements inside separate component entries, but this would still be much better.
* A way of telling what mode the installer is in during execution of the MSI. It’s easy enough to tell whether a component is being uninstalled or repaired, but you would have to look at all components to see if they are all being repaired to tell that the installer is in repair mode. Why not just publicise the Wix_InstallMode property? I know it’s there and just not accessible…
December 28th, 2007 at 18:36 #Bob Arnson
Carl,
1. I’m not sure how WiX could help here; it can’t change how MSI works (short of custom actions) and MSI requires two different components if you want an assembly in the GAC and the file system. WiX’s smart cabbing will keep only one copy of the same file in a cab. See http://robmensching.com/blog/archive/2007/06/01/quotSmart-cabbingquot-added-to-WiX-toolset.aspx for details.
2. As I mentioned on wix-users, there isn’t a single installation mode; MSI lets you mix and match in a single installation transaction. You should use feature and component states to control custom actions. The WiX custom actions use component states for the finest-grained control.
January 13th, 2008 at 14:11 #Joy of Setup » Highlights of WiX v3.0.3711
[...] 1867685: An enhancement to the change I discussed in Simplifying the WiX v3 language. [...]
February 1st, 2008 at 06:18 #Tomas
I can’t seem to get the Feature attribute of the Component element to work. Using WiX 3.0.3725 Votive allows me to add Feature attributes to Components, but I get a warning that the cabinet does not contain any files.
However, if I use a ComponentRef under the Feature element instead, it works.
However, the Feature attribute seems to be used for something, because if specify the Feature attribute on a Component AND use a ComponentRef under the Feature, I get the error “The primary key ‘MyFeatureId/MyComponentId’ is duplicated in table ‘FeatureComponents’. Please remove one of the entries or rename a part of the primary key to avoid the collision.”
Any hints?
February 1st, 2008 at 16:26 #Bob Arnson
Tomas,
I can’t reproduce that on my machine. I’ll take a look with 3725 over the weekend but in the meantime, try this sample (you’ll need fudge the files it’s including). I get no ICE warnings/errors and the File and Media tables look fine:
Edit: OK, that’s not going to work — WP doesn’t much like my pasting in XML into the comment editor. If you open a bug with your sample, I can attach mine to it.
February 2nd, 2008 at 15:44 #Tomas
Hi,
thank you for your reply. I have created a bug (http://sourceforge.net/tracker/index.php?func=detail&aid=1885447&group_id=105970&atid=642714) and assigned it to you.
I think have narrowed it down to using the Feature attribute on Heat-generated Components (that is, contained in Fragments and within DirectoryRef elements), since it works if I use a Feature attribute on a Component element directly below a Directory element.
February 4th, 2008 at 12:24 #Bob Arnson
Tomas,
The sample you posted works as expected; the problem is that nothing in your Product section references anything in the Heat-generated Fragment so the linker doesn’t include the fragment in the output. References start in the entry section (Product, in this case) and go down; a reference from a fragment into the entry section doesn’t cause the fragment to be included (though once it is, those references resolve correctly).
As Derek told me when I ran into the same problem: “Parents can pick their children, but children can’t pick their parents.”
You can see the same problem if you were to use FeatureRef in your Heat-generated fragments (which is roughly what Component/@Feature does).
February 6th, 2008 at 01:36 #Tomas
Ah, ok. I’m sorry for the faulty bug report
How then is the easiest way to include a file with components (I have one for each feature in my installation) into your “main” WiX-file that contains the Product element? Using some kind of include in the main WiX-file?
February 6th, 2008 at 21:16 #Bob Arnson
Tomas,
To be honest, if you’re using Heat, I’d use the -sfrag switch to create one fragment per harvest; when you do that, it also generates a ComponentGroup that you can use to pull in all the components with one ComponentGroupRef element. Otherwise, you’ll need one reference for every fragment.
February 8th, 2008 at 15:48 #Tomas
Bob,
Thank you for all your help. The heat switch worked perfectly together with a ComponentGroup/Ref (I noticed that heat.exe has some new info when using /?, very nice).
March 18th, 2008 at 02:04 #ewart
Hi, I’m trying to build a patch for some time and no luck; have been following the http://www.tramontana.co.hu/wix/lesson4.php#4.2 but using the latest Wix build and the tutorial is a little out of date.
The normal install works fine but the patching process is a nightmare and I’m thinking about just using that and giving up on patching - it has been is a whole world of hurt, although ironically I’m probably one setting away from suceeding! When I change
to set Compressed=”no” then I get the following error:
The cabinet ‘WixMinimalSample.cab’ does not contain any files. If this installation contains no files, this warning can likely be safely ignored. Otherwise, please add files to the cabinet or remove it.
When it’s set to “yes”, I get a full install which works nicely.
any ideas?
regards
ewart
March 18th, 2008 at 08:25 #Bob Arnson
ewart,
Please post a message with more details about your problem to wix-users.