Specifying the source file always fails

[newcomb-luke]

In order to install cargo-wix I ran cargo install cargo-wix just today, so it is the newest version.

I then ran cargo wix init, then cargo wix and it successfully generated an executable. Although I want to have two separate installers for my program, one which includes other programs as optional components, and one that does not. So I copied the main.wxs file to a different directory. I then tried to run cargo wix .\wix-full\full.wxs but that gave me:

Error[3] (Io): The '.\wix-full\full.wxs' path does not exist

I then verified that the path was correct, and tried to just run cargo wix .\wix\main.wxs and it gave me the same error:

Error[3] (Io): The '.\wix\main.wxs' path does not exist

I may be overlooking something, but to me it seems like manually specifying files is broken.

[volks73]

I have a couple of thoughts.

What shell/terminal are you using?

It is possible you need to use double backslashes for your path separators. The double backslashes should not be needed if using a Windows command prompt (cmd.exe) or similar native Windows prompt/shell/terminal. However, if running from some other terminal emulator or shell, like Git Bash, Alacritty, etc., I am not sure how paths and related path separators would work. In the UNIX world, the backslash, \, is used to escape characters. The path might be trying to escape the w and f in your path instead of recognizing the backslashes as path separators.

cargo wix .\\wix-full\\full.wxs

You could also try replacing the backslashes with forward slashes if using one of these other terminals/shells/prompts that provide UNIX-like environment. Tangentially, I believe forward-slashes, /, do work and are recognized in new releases of PowerShell (>v6/7?) as a path separator.

cargo wix ./wix-full/full.wxs

Can you run the test suite?

Can you clone this repository and checkout the v0.3.1 tag? This will be the version of the source code used with the cargo install cargo-wix command. The main branch has not been released to crates.io. In truth, I need to reorganize to move the main branch to a develop or nightly branch. There is a significant jump in features and structure between v0.3.X and main at the moment.

Anyways, there is the input_works_outside_cwd integration test in the creates.rs test module. Does this test pass?

cargo test input_works_outside_cwd

The -- --test-threads=1 argument should not be needed since you are only running one test. If want to run the full test suite, then the argument should be used:

cargo test --all-targets -- --test-threads=1

Install and run the main branch

The cargo install cargo-wix command installs the latest release from crates.io, which is v0.3.1, a.k.a. "Beta-3.1". However, the latest version of the code is available in the main branch from this repository. To install and run the latest version of the code, the --git <URL> option should be used:

cargo install --force --git https://github.com/volks73/cargo-wix.git

I added the --force in there to ensure the v0.3.1 version from crates.io is overwritten and avoids having to uninstall before installing the latest code version. After installing the main branch from the git repository, does the error still occur?

[newcomb-luke]

It has almost been an entire year since I opened this issue, but when I reinstalled cargo-wix to a new computer and tried to build, it still had this problem.

What shell/terminal are you using?

I'm using Powershell, but it also fails on Command Prompt:

Can you run the test suite?

I just decided to run the entire test suite on the new version v0.3.3, and all of the tests did pass, including input_works_outside_cwd:

Install and run the main branch

I installed and ran from the main branch, and it did indeed still have the same problem.

I'm not sure why the test would pass but it wouldn't work for me in practice, but it doesn't seem to be working.

[volks73]

Thank you for the update and information. I believe the issue is actually some confusion on both our parts on the usage of the cargo wix default command and the <INPUT> argument.

A while back, I changed the <INPUT> argument to accept a Cargo.toml file instead of WXS files (#70). There is also an open issue about adding a --manifest-path like other Cargo commands and changing the <INPUT> argument (#160). The <INPUT> argument is looking for a Cargo.toml, i.e. package/project manifest, file, not the main.wxs file. I missed this from your first post. The help text from the current released version of the subcommand, cargo wix --help, displays:

ARGS:
    <INPUT>
            If no value is provided, then the current working directory (CWD) will be used to locate a package's
            manifest. An error will occur if a manifest cannot be found. A relative or absolute path to a package's
            manifest (Cargo.toml) file can be used. Only one manifest is allowed. The creation of an installer will be
            relative to the specified manifest.

This would explain why the test suite is passing and the default cargo wix command works as expected.

You appear to have a one Cargo.toml file and would like multiple installers. I believe you want to use the -I,--include option:

    -I, --include <include>...
            Includes a WiX source (wxs) file for a project, where the wxs file is not located in the default location,
            i.e. 'wix'. Use this option multiple times to include multiple wxs files.

for your alternative/secondary installer. So, something like cargo wix -I .\wix-full\full.wxs from your first usage attempt.

[newcomb-luke]

Ah I see. That makes sense now.

I would recommend for anyone who sees this, or yourself, to try to update to a better error message. Saying that it is the incorrect type of file instead of "path does not exist".

[volks73]

I would recommend for anyone who sees this, or yourself, to try to update to a better error message. Saying that it is the incorrect type of file instead of "path does not exist".

Good idea! I have created #173 and will merge it after CI passes. Closing this issue as it appears to be have been resolved.