Feature tags are used when we want the WiX project to actually do something. It’s usually a step after we have defined the file location of whatever it is we want to drop. Let’s say we have declared the folder location “bin” already. Typically we’d want to declare dropping any dlls at the end of the product.wxs file, after we have created the drop location. The reason I like to do it this way is that it creates a logical organisation to the WiX file.

<Feature Id="ProductFeature" Title="RP.Nix" Level="1">
<ComponentGroupRef Id="Bin"/>
<ComponentGroupRef Id="Services"/>
</Feature>
</Product>

The ID is always unique to the Feature tag, as is the Title. The Level is always defaulted to 1. If you want to disable this feature, then change the level to 0. As you can see, you can have more than one child element referenced in the Feature tag. In this feature we have a ComponentGroupRef which is a reference to a ComponentGroup in another fragment.

<?xml version="1.0" encoding="UTF-8"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi">
<Fragment>
<ComponentGroup Id="Bin">
<ComponentGroupRef Id="Commands"/>
<ComponentGroupRef Id="Queries"/>
</ComponentGroup>
</Fragment>
</Wix>

You can even embed another ComponentGroupRef within the ComponentGroup. You might want to do this to keep the size of the files within your solution down.

<ComponentGroup Id="Commands">
<ComponentRef Id="FILE_$(CommandDll.TargetFileName)" />
</ComponentGroup>

At the base of this all is the Component tag, in which we create our action. Here we are just copying 1 dll in the solution, but if you have 40-50 you may want to logically group them to save having a 1000+ line xml file that may crash Visual Studio…

<DirectoryRef Id="Bin">
<Component Id="FILE_$(CommandDll.TargetFileName)"
Guid="{1CCFC954-2373-42A0-B5CA-D72D83C0F7F8}" >
<File Id="$(CommandDll.TargetFileName)"
Name="$(CommandDll.TargetFileName)"
Source="$(var.CommandDll.TargetPath)" />
</Component>

Summary

Above is a very simple example of using a ComponentGroupRef to call into another fragment into another file. Within that ComponentGroup we can place more ComponentGroupRef tags to other ComponentGroups. Or we can add a ComponentRef tag to a particular Component that we want executed. The structure is down to the user. I tend to use Features and Components to help organize the installer project in Visual Studio into similar actions, like copying dlls or finding and replacing text in the web.config.

Sources