Ephemeral Builds and Command

[volks73]

I have been thinking about the implementation of this feature and would appreciate some comments on the following:

1. What should the name of the option be? We have discussed --product-guid option for the create (default) command, but I am actually leaning towards a new subcommand: cargo wix ephemeral <UPGRADE-CODE-GUID> <PATH-GUID> <WXS-FILE>|<CARGO-TOML>. The <UPGRADE-CODE-GUID> and <PATH-GUID> (See Item 3) would be required, while <WXS-FILE>|<CARGO-TOML> would be optional. If specified, a customized WXS file could be used, but it would need to contain the WIX variables for the Upgrade Code and path, respectively (See Item 2). This would allow users to generate a WXS file once with the cargo wix init command, customize as necessary, but store the Upgrade and Path GUIDs somewhere else. If not specified or the value is a path to a Cargo.toml file, the internal ephemeral template (See Item 2) would be used. The issue is that the GUIDs must be supplied and what is the best way to make this obvious and ergomonic?
2. The WXS template will need to be updated to include/exclude a WIX variable for the Upgrade Code and PATH Guid so the GUIDs can be passed through the CLI.
3. Does the PATH system environment variable need a hard-coded/explicit GUID? It was a long time ago that I developed and tested the current WXS template. I think the GUID needs to be hard-coded/explicit so that it is properly uninstalled and/or not added twice during upgrades. Then, we need to figure out how to require this value and the upgrade code GUID in the CLI and a WIX variable will need to be added for the PATH GUID.
4. The cargo wix print subcommand will need a new flag or new template value to allow for printing of the concrete WXS template (auto-generates a GUID each time) or the ephemeral WXS template (includes the WIX variables).
5. Does a separate ephemeral.rs source file need to be created or should the create.rs be updated with two Execution types: Concrete and Ephemeral? The answer to this question would be: Is the Builder the same for both "creation" executions?
6. Links and information for generating GUIDs outside of cargo wix should be added to the crate's documentation. Is a cargo wix guid command needed/useful?
7. If and when Add support for a Wix.toml manifest #20 is implemented, an ephemeral field with Upgrade Code and PATH Guid sub-fields would be needed.

Some additional comments and background:

All data that cargo wix init currently takes fron Cargo.toml can possibly change and if WXS is not meant to be regenerated, that data will need to be updated in two places.

Having to update the same information in multiple places ultimately leads to chaos.

I think the variability of the contents of the Cargo.toml file and use of a concrete WXS file is related to the timing of the project's development process and introduction of an installer. Do you want, or need, an installer during the early stages of project development when configurations, names, etc. are highly instable (changing frequently), or is an installer only needed in later, stable stages of project development? There is no right or wrong answer to this question, but currently cargo wix is only supporting the late, stable stage of development, which is mostly due to its origin story.

The subcommand came about from another project where I needed to create a Windows installer for an existing, stable project and I had several other cargo-related, stable projects that would benefit from Windows installers. I was copying-n-pasting the same WXS file over-and-over and making small modifications to the product name, upgrade code, etc. which we all agree is a source of pain and headaches. So, cargo wix was the solution to adding installers to late stage development projects.

Originally posted by @volks73 in #85 (comment)

[volks73]

Instead of cargo wix ephemeral <Upgrade-GUID> <Path-GUID> and having them be required, I am thinking about making them options, --upgrade-guid and --path-guid instead. This way a "one-off" installer with auto-generated GUIDs can be created with the same command. If these options are not specified, then just like the cargo wix print wxs command, new GUIDs are generated each time. I am not sure the utility of this, but if someone needed to just create a quick installer on-the-fly with this command and the GUIDs are required arguments, they would have first generate the GUIDs from some other mechanism and then presumably copy-n-paste into the cargo wix ephemeral command, and then execute; whereas, if they are optional the one-off installer can be created in a single step and it would still be possible to use a GUID stored somewhere else.

[volks73]

A separate ephemeral.rs module from the create.rs module will need to be created. The builders are ultimately going to be different and have different methods/options. It also just fits better with the organization for the project where each command is a separate module.

[volks73]

So, I actually now think this is overkill. If an "ephemeral" installer is desired, then this can be handled with adding an -U, --upgrade-code and --path-guid options for the cargo wix init and cargo wix print subcommands and an external-to-this-project script, such as a GitHub action or some other CI build process. For example, if the -U, --upgrade-code and --path-guid options existed, then they would also be supported with metadata fields. This provides a single location for storing the GUIDs in the package's manifest (Cargo.toml) under the package.metadata.wix section. Thus, the following series of commands would create "ephemeral" installers:

C:\>cargo wix init --upgrade-code <UPGRADE_CODE_GUID> --path-guid <PATH_GUID>
C:\>cargo wix
C:\>del /S wix

where the <UPGRADE_CODE_GUID> and <PATH_GUID> would be replaced in the script or CI configuration file with the actual values.

Alternatively, if the following package manifest was defined:

[package.metadata.wix]
upgrade-code = "<UPGRADE_CODE_GUID>"
path-guid = "<PATH_GUID>"

then the script or CI configuration would be:

C:\>cargo wix init
C:\>cargo wix
C:\>del /S wix

and every time the script or CI executed, the same GUIDs would be used (pulled from the package's manifest) when the installer is created.

The del /S wix is needed to remove the wix directory that is created with the cargo wix init subcommand but to leave the created MSI left in the target\wix directory. There is currently no cargo wix subcommand to leave the build output but delete the source. The cargo wix clean command deletes the build output and the cargo wix purge command deletes the build output and the source.

Note, under normal usage, the --upgrade-code and --path-guid options would only need to be used once to generate the WXS file template with the cargo wix init subcommand and the package metadata fields should not be used. The GUIDs would be stored in the WXS file and would not need to be saved elsewhere.

This implementation would not affect the create (default) subcommand. No WiX variables are needed and no separate templates or subcommands would be needed.

[volks73]

With implementations for passing GUIDs during the initialize and print subcommands with #116 and #117 combined with the latest comment, I think this issue is resolved.