volks73 / cargo-wix Goto Github PK

If the WIX_PATH environment variable exists, then this subcommand should use the value of the environment variable as the path to the WiX Toolset's bin folder, i.e. where the candle.exe and light.exe applications are located. If it is not set, then it is assumed the WiX Toolset's bin folder is in the PATH system environment variables (current behavior).

There will need to be a way for users to specify the path to the WiX Toolset's bin folder and/or compiler and linker outside of the PATH system environment variable. It is possible not everyone can modify his or her PATH or that a different version of the WiX Toolset is to be temporarily used.

If an error occurs with the builder (cargo build --release), compiler (candle), linker (light), or signer (signtool), then a simply, generic "failure has occurred" message is printed. Ideally, the stderr from the failing command should be the error message, or at the very least the exit code should be included with the error message.

Currently, cargo-wix will ignore the license-file field and only work when the license given is a builtin one.

Ex. if I have a cargo project with license-file="LICENSE", cargo-wix ignores it completeley and tells me that it couldn't generate an appropriate license file:

• You are only checking the license field here, not the license-file field. So it will fail to build the MSI if you are not specifying a license identifier, but a license in a seperate file.

Information about the WIX_PATH environment variable and the precedence for finding the compiler (candle.exe) and linker (light.exe) is missing from the CLI help (--help). This information is available in the online documentation under the Concepts section as:

The WiX Toolset provides a compiler (candle.exe) and linker (light.exe). These can be found in the bin directory of the installation location for the WiX Toolset. This subcommand uses these two applications with the std::process::Command module to create an installer. Generally, it is best to add the WiX Toolset bin folder to the PATH system environment variable, but a WIX_PATH environment variable or the -B,--bin-path option can be used to specify a path (relative or absolute) to the WiX Toolset bin folder. The order of precedence (descending) is: -B,--bin-path option, WIX_PATH environment variable, and then the PATH system environment variable.

but not in the sub-command's help text.

If you support a seperate [wix] section - what keys / values are valid? For example, it would be nice, not to add the main.wxs into source control. It would be great if settings (app icon, banner, help / documentation link, etc.) could be set via the Cargo.toml file instead of the main.wxs file:

Also, it would be great, if you could support a "nice name". Cargo will complain if you capitalize the package name (which is OK), but for a user it's often more friendly to have a capitalized name

I.e. something like this:

[package]
name = "something"

[package.metadata.wix]
nice-name = "Something Editor Pro"
icon = "assets/main.ico"
help = "http://company.com/support"
install-banner-picture = "assets/Banner.bmp"
install-dialog-picture = "assets/Dialog.bmp"

It would be great if this could be done directly in the Cargo.toml file, so that the main.wxs file doesn't need to be checked into version control. If something like this is already possible, it would be good to have some documentation on which fields / keys are valid.

When using the -s,--sign flag, the /d switch for the signtool should be used to set the subject of the Authenticode dialog to the name of the product, not the random hex string.msi name.

The /du switch should be used with the signtool to specify a URL for the signed content. This would be taken from the homepage field of the package's manifest (Cargo.toml). If the homepage is not set in the manifest, then the /du switch is not used when signing the installer.

The --print-license option should be added. It would accept the ID of the license as a value and print it to stdout, similar to the --print-template flag. This would also users to create license files from the support templates. Note, the output would be RTF, so not very human-readable, but redirection can be used to create a RTF file from the output and viewed using WordPad.

The -b,--binary-name option would override the name field for the bin section of the package's manfiest (Cargo.toml), which is used for the executable name within the installer. This allows the user to change from defaults for specific configurations.

As mentioned in #29, the --print-template option would accept WXS, MIT, Apache-2.0, and GPL-3.0 as valid values and print the corresponding template to stdout. Values would be case insensitive. This would provide a more generalized way to print the various templates, and future templates, to stdout or file.

The -a,--author option would override using the first author in the authors field of the package's manifest (Cargo.toml). It would take a value. This would be used for the Manufacturer attribute of the Package element of the WiX Source in the template.

The following message appears when a LICENSE file does not exist for a project:

WARN: A 'LICENSE' file does not exist in the project root. Please consider adding a such a file to avoid errors during installer creation.

There is an extraneous a before such in the sentence.

Instead of returning an error if the -d,--description option or description field in the package's manifest does not exist, the empty string should be used and a warning issued instead.

The --print-template flag should be changed to an option with an optional value. If a value is supplied, then the template is printed to the path specified in the value, but if no value is supplied (default), then the template is printed to stdout. This saves the need for redirecting. The subcommand should also ensure the full path to the file exists, i.e. folders are created if needed.

The entire error message is printed in red, not just the "tag", which is the portion to the left of the colon, :, before the message. The tag should be red, but not message.

The clap argument parser supports short and long help messages where the -h flag displays the short help message and the --help flag displays the long help message. This is pretty cool. The -h,--help documentation for this subcommand should be refactored to support a short, quick message and a longer, more detailed message.

A License Agreement Rich Text Format (RTF) file should be generated based on the license field in a package's manifest (Cargo.toml) when the --init flag is used. The WixUI_FeatureTree dialog set is used within the embedded template because it displays a dialog for customizing the installation. All the built-in dialog sets for the WiX Toolset have a License dialog of some kind. A generic placeholder is used if the <WixVariable Id='WixUILicenseRtf' Value='wix\License.rtf'/> tag is not used or uncommented, but we should be able to use the license information from the package manifest to automatically replace the generic placeholder with the package-specific license.

For example, if the license field for the package section is set to GPL-3.0, then the GPL-3.0 license in the RTF format should be automatically generated. Custom licenses would require manual modification of the WiX Source (wxs) file, but the licenses supported by the license field should be automatic. There are a lot of supported license identifiers, so maybe just initially support the most common ones used by Rust project: Apache-2.0, MIT, and GPL-3.0.

If the license-file field is used in the package manfiest, then it is used for the License.rtf file, but I am not sure how convert the file to RTF automatically. I am also not sure how to handle the various RTF files. Should there be a pre-built RTF file for each license embedded in the binary?

There is also the matter of the License file being included in the installation location directory afterwards as well. How should this be handled?

All of the "commands", such as --print-template, --clean, --init, etc., also "run". So, the method used to build, and/or create, the Windows installer should be renamed from run to build. The create method is also a possibility.

The --no-build flag will skip building the release binary. This is to match functionality in the cargo-deb project.

Aliases should be added for the SHA-256 compatible timestamp servers. The URLs for some of these are different than for the SHA-1 timestamp servers.

A warning message should be displayed during initialization (cargo wix --init) if the license-file field is not set and a LICENSE file is not present in the root directory. If the license-file field is set, it is ultimately used for the license source, so there is no warning or error. This is a warning instead of an error because the user could use the -l,--license option during installer creation.

The -o,--output option would indicate an alternative location for the output of the create method instead of the target\wix folder. If used, the build artifacts, such as the wixobj file would be created in a temporary directory that is destroyed after the MSI is created. This would be useful for creating an installer with a destination in another location.

The mustache-rust and guid crates should be used to automatically replace the placeholders in the template for the UpgradeCode and Path Guid attributes with new GUIDs each time the --print-template flag is used.

This will eliminate the need for manual modification after printing the template to use it with this subcommand.

The Windows 10 prompt supports ANSI escape sequences, so console colors can be easily achieved, but older versions of Windows do not support ANSI escape sequences. The termcolor crate provides console coloring for all versions of Windows. It might be better to switch to the termcolor crate to support older versions of Windows.

FYI, the termcolor crate is used in cargo.

A -t,--timestamp option should be added to change the timestamp server URL for the signtool during signing of the installer. Right now it is hard-coded to Comodo's timestamp server because that is what I have used in the past for other projects. Ideally, it would be nice to have a [wix] section in the project's manifest (Cargo.toml) that has a timstamp-url field so that it does not have to be constantly specified at the command line.

This option would only be valid if the -s,--sign flag is also used.

The -p,--product-name option would override the name field for the package's manifest (Cargo.toml), which is used for the installer's ProductName attributes and values. This would allow users to deviate from default behavior and have the product name be more end-user friendly than the developer's product name.

Similar to the WIX_PATH environment variables, a SIGNTOOL_PATH environment variable should be supported. This would allow using a different installation of the signtool application available with the Windows SDK.

If a help URL cannot be determined, then a warning should be printed to add the documentation, homepage, or repository fields to the package's manifest. The Help URL is only needed if the ARPHELPLINK is uncommented from the main.wxs file.

If a Wix.toml manifest exists in the root of the project or in the wix folder, then the fields within this file are used when building, compiling, linking, and signing. When the --init flag is used, a Wix.toml file is created in the wix folder as part of the initialization of the wix sub-project.

The --print-template flag should be renamed to --print-wxs, --print-main-wxs, --print-main, or something similar. Now that there are templates for licenses, the --print-template flag is a little ambiguous. The --print-template flag could be changed to an option that accepts the ID for a license or Wxs and prints the template to stdout.

If there is an error, then console turns red for all commands following the completion of this sub-command. It appears this sub-command changes the terminal color to print the error but does not change the color back after printing.

The --clean flag would delete/remove the target\wix folder if present, similar to the cargo clean subcommand.

The --purge flag would delete/remote the target\wix folder and the wix "source" folder that was created with the --init flag if present. This should be used with caution and possibly display a confirmation prompt to complete the action because other files might be present in the wix folder, like images and licenses.

Log statements currently hide the module path unless the verbosity is greater than four (4). In reality, the module path is never very useful for this project because all of the code is in one module, i.e. cargo_wix. The line numbers should be toggle on and off based on verbosity, but the module path should also be off. This will simplify the main function implementation and yield cleaner log statements with more focused, useful information.

The --write-template option would take a value identical to the --print-template option, but it would also use the INPUT positional argument to write the template to the path specified in the INPUT instead of just writing to stdout.

This is a nice to have and it might not be worth the hassle because redirection could just be used to create the file with the --print-template option. It is an idea.

I'm trying to build a project, but all I'm getting as an error is "The system can't find the file (os error 2)". It would be really helpful to know what file exactly it can't find or where the error came from.

The <INPUT> argument should be added. This takes a path to a WiX Source (wxs) file. When specified with this subcommand, the installer will be created using this wxs file instead of searching for the wix\main.wxs file (default). This will allow users to deviate from convention for custom configurations and project layouts.

The registry key, ARPINSTALLOCATION, is not being set during installation with an installer created using this subcommand and the main.wxs.mustache template.

If a Rich Text Format (RTF) license file could not be found or generated during initialization, a warn statement should be printed. This is a warning because the developer may manually change the WiX Source (wxs) file to handle the EULA for the installer but it will be an error during building of the installer if no License.rtf file is found.

Similar to the #24 feature, the -W,--wix-path option should be added to the CLI so that the path to the WiX Toolset bin folder can be specified at the command line in addition to an environment variable. The precedence, with the first overriding the next, would be:

1. -W,--wix-path option
2. WIX_PATH environment variable
3. PATH system environment variable

This allows for the subcommand to take into account the build environment, one-off execution, and defaults. Currently, only the PATH system environment variable is supported.

The platform is defaulted to x86 (32-bit) and there is a --x64 option to build the installer for the x64 platform instead of the x86 (32-bit) platform. However, it should be possible to determine this option based on the installation of this subcommand, i.e. at compile-time. If the subcommand is installed using the x86 toolchain with rustup, then it should use the x86 (32-bit) platform. If the subcommand is installed using the x64 toolchain with rustup, then it should use the x64 platform.

Conditional compilation should make this possible.

The -d,--description option would take a value that overrides the description field of the package's manfiest (Cargo.toml) for the description within the installer. By default, the description field is used for the installer description. This would allow users to override the contents specifically for the installer.

A check should be added for the description field in the project's manifest when initializing. If the description field is not found, a warning message should be displayed indicating an error may occur if a description is not added for the project or the -d,--description option is not used when building the installer.

The --init flag should be added to the Command Line Interface (CLI) for the cargo subcommand. This would function similar to the cargo init subcommand, but it would create the wix subfolder in the project's root directory and print the template into the wix\main.wxs file. In other words, it would initialize the installer portion of the project.

The loggerv crate uses the ansi_term crate for colorized output, so enabling ANSI escape sequences on Windows 10 is still needed to prevent preventing ANSI escape characters in the log messages. The ansi_term and atty crates dependencies still exist.

I believe the same verbosity-based logging functionality can be achieved with the env_logger crate, which uses the termcolor crate for coloring and would also add setting the log level from an environment variable.

It should be noted that the clap crate also uses the ansi_term crate for coloring but it handles the enabling of ANSI escape sequences for Windows 10 internally. Another alternative would be to add this internal functionality to the loggerv crate.

The run method of the Wix struct should be refactored to use private methods, so that the various functionality and execution of the run method can be better tested. Unit tests can be created for the private methods to ensure behavior of the overall execution of the run method is correct.

Currently the /a flag is used with the signtool application for signing installers. This is fine most of the time as it indicates the application will automatically search for a suitable certificate in the Windows certificate manager. However, there are edge cases where someone may have multiple "suitable" certificates and want to specify a specific one to use. So, a -c,--certificate option should be added that takes a path and/or name to certificate to use when signing an installer with the -s,--sign flag.

Aliases for the URLs to various timestamp servers for certificates should be added to the subcommand and used with the -t,--timestamp option. For example, instead of having to remember the full URL for the Comodo timestamp server and enter it at the CLI, the "alias" Comodo could be used for the option value. Similar to origin and upstream are aliases for the URLs in git repositories.

The project fails to build and install when using the i686 toolchain. This appears to be a problem with the ansi_term crate. An issue has been submitted to that project. Until this can be resolved within the dependency, the subcommand only works for the x86_64 toolchain.

The -S,--sign-path option would function similar to the -B,--bin-path option but for the SignTool application instead of the WiX Toolset bin folder. This would override the PATH system environment variable or any environment variables established when using the Developer Prompt. The value should be a path to the bin folder for the Windows SDK that includes the signtool.exe file.

If an email is provided in the first author string for the authors field and the first author is used for the Manufacturer, the email should be stripped; otherwise, it appears in the "Publisher" column in the Add/Remove Programs control panel.