Support multiple binaries in Cargo.toml

[slonopotamus]

Currently, cargo-wix uses only uses the first binary defined in Cargo.toml:

cargo-wix/src/print/wxs.rs

Line 350 in 7982417

.and_then(|a| a.get(0))

However, it is perfectly valid to have multiple binaries in a single Cargo.toml. So, ideally, cargo-wix should collect a list of binaries and handle them all.

[volks73]

I agree, cargo-wix should support projects with multiple binaries. The mustache template will need to be updated to loop through an array of binaries in addition to the highlighted section of code being modified to generate a Vec of binaries instead of a single item.

I would greatly appreciate a pull request that adds this functionality.

In the mean time, it is possible to add the additional binaries to the generated main.wxs file after it is initially generated. The XML for the single binary can just be copy-n-paste with modification for each binary as follows:

Single binary:

<!-- ... -->
<Component Id='exampleBinary' Guid='*' Win64='$(var.Win64)'>
  <File
    Id='exampleEXE'
    Name='example.exe'
    DiskId='1'
    Source='target\release\example.exe'
    KeyPath='yes'/>
</Component>
<!-- ... -->

Multiple binaries:

<!-- ... -->
<Component Id='exampleBinary0' Guid='*' Win64='$(var.Win64)'>
  <File
    Id='exampleEXE0'
    Name='example0.exe'
    DiskId='1'
    Source='target\release\example0.exe'
    KeyPath='yes'/>
</Component>
<Component Id='exampleBinary1' Guid='*' Win64='$(var.Win64)'>
  <File
    Id='exampleEXE1'
    Name='example1.exe'
    DiskId='1'
    Source='target\release\example1.exe'
    KeyPath='yes'/>
</Component>
<Component Id='exampleBinary2' Guid='*' Win64='$(var.Win64)'>
  <File
    Id='exampleEXE2'
    Name='example2.exe'
    DiskId='1'
    Source='target\release\example2.exe'
    KeyPath='yes'/>
</Component>
<!-- ... -->

The first binary is only read and used for the cargo wix init command. If you modify the main.wxs file after initialization/generation, the cargo wix command should also include the additional binaries without having to re-generate the WXS file.

[volks73]

I looked into this a little more. The problem is not reading from the manifest file (Cargo.toml) and looping through the binaries, but the CLI. There is the -B,--binary <binary> option for the cargo wix init command that allows the user to the executable file that is included in the installer. I believe this is a very rarely used option, but how should this work for multiple binaries?

My initial ideas are to allow the option to appear multiple times and the where each occurrence relates to a binary. The order would need to match the order in the Cargo.toml file. Another thought is to remove the option if it is rarely used.

[volks73]

Oh, there is another complication. Should each binary be listed as a separate component in the installer that can be toggled for installation or are all binaries a single component, an all or nothing situation? In the first scenario, each File tag would need to be in a separate Component tag and later on a ComponentRef tag added to the Feature tag. The second scenario is depicted in the above workaround.

I think the default should be the all or nothing approach and a CLI flag/option added to switch to the separate component situation can be added. I think the majority of the time, developers will want users to install all of the binaries, and all of the binaries are need for the application to run correctly.

[slonopotamus]

how should this work for multiple binaries

Or it could only support a single binary :)

I believe this is a very rarely used option

I highly suspect that common scenario is just use cargo wix init without any parameters at all, expecting it to do The Right Thing based on Cargo.toml.

majority of the time, developers will want users to install all of the binaries

This sounds like a good default behavior.

[volks73]

Implemented as of d369e84.

I have added support for multiple binaries defined in the package's manifest (Cargo.toml). They are all included within the same "feature" for the installer. I have not added the option to break out each binary into separate features (checkboxes for each to install within the GUI) because that appears to be a little more work to implement as an option/toggle within the mustache template and I think the default behavior of including all binaries with the "application" feature is the more common use case.

The -B,--binary option for the initialize and print subcommands has been changed. Multiple occurrences are now allowed where each occurrence is a path to an executable file to include in the installer instead of the binaries defined in the package's manifest. It is an "all-or-nothing" option. It cannot append executables to the installer, only override which are included. If "external" and "internal" (those defined within the package's manifest) are to be included in the installer, then the "internal" binaries will need to be specified with the -B,--binary option along with the "external" binaries. Basically, once a single -B,--binary option is used, the package's [[bin]] and name fields are ignored. A path is used for the value.

There are a couple more changes I think I would like to add before making a new release, but the changes are available on the master branch.