Add support for bundled installer

[Coding-Badly]

The essence of the request is to allow the final filename extension to optionally be exe instead of being hard-coded to be msi. Everything else needed is available with the new -C and -L options.

My first thought is -x or -extension followed by the extension.

[volks73]

Thank you for the enhancement request. I do not have much (any) experience creating WiX bundles, other than I know it is possible. According to the PR you provided (#99), a WiX bundle has a .exe file extension and the linker (light.exe) complains if the extension is not .exe, where as a regular installer has an .msi file extension. Given this information and my lack of experience with WiX bundles, I have a couple of questions:

1. Does the WiX bundle's file extension have to be exe or are there any other file extensions that are allowed?
2. Based on Q1, can the -x,--extension option be a flag instead, i.e. no value that simply toggles between either two possible values: msi or exe?
3. Is there a way to determine before the linker is invoked that a bundle is to be created instead of a MSI, without inspecting the WXS file? I am wondering if changing the file extension could be automatic? If the complaint by the linker of the wrong file extension is a specific error code every time, then maybe we can just look for this error and retry the linker command with the exe file extension, but this might be too much "magic" and hacky.
4. What are the other flags and options that need to be passed to the compiler and linker to create a bundle? Are these always the same for any bundle? Relative to Q3, can all of these be condensed down to a single --bundle flag for the default create subcommmand that automatically adds the necessary compiler and linker arguments and changes the file extension from msi to exe?
5. Would WiX bundles be appropriate for supporting workspaces (Multi-crate workspace projects support #74) and a possible project layout where each child package in a workspace is a MSI and a bundle is created for the entire workspace versus a single MSI for the whole workspace with each package as a "feature"?

I kind of see this enhancement request as actually two separate, but complementary requests: (i) Adding support for bundles and (ii) adding an option/flag to change the file extension. PR #99 addresses the latter (adding option/flag to change file extension), and is a near-term resolution/workaround, while the former (supporting bundles) is a longer-term resolution/workaround. If you (@Coding-Badly) agree, then let's create a second issue/enhancement for the file extension enhancement because the title of this issue is already about supporting bundles.

I would recommend making the option/flag be -x,--file-ext instead of -x,--extension to avoid confusion with WiX extensions. The "file" component more clearly indicates this is related to the output filename than some plugin/add-on to the installer creation process. I would also make the Cargo.toml metadata field to be file-ext or preferably file-extension. If the file extension can only be msi or exe (Q1 and Q2), I would seriously consider changing this to a flag and even renaming it to --exe-extension and the metadata field being a boolean, exe-extension.

Sorry, I know you (@Coding-Badly) already submitted a PR with the -x,--extension implementation (thank you, by the way!). I will note this in the PR as well.

[Coding-Badly]

1. I don't know. I assume exe is the only supported extension based on what's being built. I've only ever seen installers with msi or exe extension.

2. I'm leaning towards a flag that indicates "building a bundle". That gives a nice bucket for anything else bundle related that comes up and I think that better conveys the intent from the user's perspective (e.g. I want to build a bundle.)

3. Yes, there is a way. Inspecting the wxiobj file (compiler output) seems the best choice. The second element seems to always indicate product or bundle. If I had time I was going to try including automatic detection by peeking into the wxiobj file.

4. I had to stop using the wix directory. cargo-wix slurps up all the wxs files which just does not work for what I'm doing. But, having wix/msi and wix/exe directories worked better overall. The only other thing I had to change was the target extension. Everything else worked the same whether I was building an msi or an exe. I agree. A --bundle option seems like a much better choice.

5. I have no idea. I'm not using workspaces, have not used them, and have no plans to use them so I'm not in a good position to even opine.

...actually two separate, but complementary requests...

Based on the Q&A I disagree. I think just a --bundle option is the way to go. For now the only difference would be the filename extension. A good future enhancement would be to peek into the compiler output then set --bundle appropriately.

Regarding "extension": Yeah. That was a bad choice.

Please let me know how you'd like to proceed. Any path forward that directly or indirectly gets the filename extension to exe will work for me.

[volks73]

Great! Thanks for the reply and answers.

I agree, it sounds like a flag to indicate creating a bundle versus a MSI is the way forward. The -B,--bundle flag with the appropriate bundle boolean field for the metadata works for me. Note, the lowercase short -b is used by the -b,--bin-path option for the default create subcommand so the uppercase -B is needed for the short argument, but I am also cool with only the long form, --bundle being available.

If I had to guess, too, only msi and exe are supported. Why would the WiX linker even check the file extension? Unless there was a desire to keep file extensions uniform and consistent. It seems a little odd the linker is concerned about the output file name and file extension.

For now, the -B,--bundle flag would just set the file extension to .exe instead of .msi. Any future bundling requirements can be pushed into this flag if needed.

The automatic detection would be a cool feature/enhancement, but let's move that to a separate issue for tracking purposes and no rush on getting that implemented. I understand the desire/need to just get cargo-wix to change the file extension for your project.

[Coding-Badly]

Why would the WiX linker even check the file extension?

It gets worse. If no extension is specified it builds without one and complains!

I should have a pull request ready by tomorrow.

Thank you again for this great project!

[volks73]

Thank you again for this great project!

Your welcome!

Why would the WiX linker even check the file extension?

It gets worse. If no extension is specified it builds without one and complains!

Even more weird. I just did a brief test using the -o,--output option for cargo-wix with the default create subcommand. I wanted to see if I there were any errors if I was trying to build a MSI with a different file extension, not a WiX bundle. I executed the following commands from a basic Cargo project.

C:\Path\To\Project> cargo wix init
C:\Path\To\Project> cargo wix -o test.exe
C:\Path\to\Project> cargo wix -o test.aaa
C:\Path\to\Project> cargo wix -o test.msi

I received no warnings or errors from the WiX linker with any of the invocations. However, if I used a .exe file extension, I would get an error from Windows 10 saying I could not run this application. If I used a file extension, like .aaa, Windows 10 would complain about not knowing the file extension and not recognizing a program to execute for the file.

All three commands generated a file from the WiX compiler and linker without any complaints. This was on Windows 10 with WiX Toolset v3.11. So, maybe the file extension check is only for WiX bundles when the <Bundle> tag is present in the WXS file?

This does not change anything with regard to implementation. I just wanted to add some more data to situation. I think the -B,--bundle flag is still the way to go. There was a moment when I thought maybe a --exe-file-extension flag might be needed/useful if you could create an installer with the .exe file extension that was not a WiX bundle and have it still work. That moment has past with this series of tests.

[volks73]

Some experimentation with creating a workspace-based project and installer bundles has yielded the follow observations and conclusions:

Assuming the following Rust project structure:

|-- Path\to\Rust\Project\Root
|-- Cargo.toml <-- Workspace
|-- |-- client
|-- |-- |-- |-- main.wxs <-- MSI client definition
|-- |-- core <-- No installer because it is not a binary
|-- |-- server
|-- |-- |-- wix
|-- |-- |-- |-- main.wxs <-- MSI server definition
|-- |-- wix
|-- |-- |-- main.wxs <-- Bundle definition

The most basic bundle definition would probably be the following for this project layout:

<?xml version="1.0"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi">
    <Bundle Version="1.0.0" UpgradeCode="[GUID]">
        <BootstrapperApplicationRef Id="WixStandardBootstrapperApplication.RtfLicense"/>
        <Chain>
            <MsiPackage SourceFile="client\target\wix\client-0.1.0-x86_64.msi" />
            <MsiPackage SourceFile="server\target\wix\server-0.1.0-x86_64.msi" />
        </Chain>
    </Bundle>
</Wix>

This would require separate WiX Source files or WiX projects for each binary and have the MSI for each binary built before the bundle could be built. In other words, a bundle could not be created with a single cargo wix command. The following would need to be executed from the root of the Rust workspace-based project:

PS> cargo wix client\Cargo.toml
PS> cargo wix server\Cargo.toml
PS> cargo wix --name Bundle-Name --installer-version 1.0.0

A bundle installer will be built. Note, these experiments were run with the latest revisions from PR#99, so the automatic bundle detection and EXE rename is working.

Creating the client and server WXS files is currently possible with this subcommand, i.e. cargo wix init client\Cargo.toml and cargo wix init server\Cargo.toml, but this would also be multiple commands and the Bundle definition would have to be manually created.

The --name and --installer-version options could be moved to a [package.metadata.wix] section in the virtual manifest for the workspace, i.e. space Cargo.toml file as the [members] section. So, the third invocation could be simplified without any changes to the subcommand implementation.

This is all a little cumbersome, but definitely doable. I don't think #99 will ultimately address full support for bundles, but it is a start. This is also working under the assumption that bundles are only really used in conjunction with workspace-based Rust projects. I have not experimented or put a lot of thought into normal Rust projects that would use bundles versus to MSI.

There is also the possibility of not using bundles with workspaces that would need to be addressed. So, adding full bundle support would also be closely tied to #74.

[volks73]

I believe the original request in this issue has been resolved with the merging of #99. I have created #101 to track and discuss the creation of a template for bundles as related to workspaces, which is a separate feature but would add "full" support for both bundles and workspaces.