Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Better error messages than "can't find file" #46

Closed
fschutt opened this issue May 9, 2018 · 6 comments
Closed

Better error messages than "can't find file" #46

fschutt opened this issue May 9, 2018 · 6 comments
Assignees

Comments

@fschutt
Copy link

fschutt commented May 9, 2018

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.

@volks73
Copy link
Owner

volks73 commented May 9, 2018

Yes, that is way too generic, and I can see how that is very frustrating. I will investigate and implement a better error message.

Were you able to eventually build your project and/or discover which file was missing? Did you try to use the sub-command with a higher verbosity, i.e. > cargo wix -vvv and if so, what was the output like?

@volks73 volks73 self-assigned this May 9, 2018
volks73 added a commit that referenced this issue May 10, 2018
The path to the `bin` folder for the compiler of the WiX Toolset is
checked for existence before starting the compiler. A better error
message is provided if the path does not exist and/or the compiler
cannot be found than the standard, generic IO error message.

This should possibly resolve:

- [Issue #46](#46)
volks73 added a commit that referenced this issue May 10, 2018
Similar to the error messages that were added for finding the compiler
(candle), better error messages were added for the linker (light).

Related to:

- [Issue #46](#46)
volks73 added a commit that referenced this issue May 10, 2018
If the compiler and linker applications could not be found in the PATH
environment variable, which is the default behavior, the sub-command
would emit a generic file not found OS Error (2), which is an IO error.
This is too generic and may be the source of Issue #46.

A better error message is provided, but the only way to know if this
worked is to attempt the compiler and/or linker command and then map the
IO error if the kind is `NotFound` to a Generic error.
@volks73
Copy link
Owner

volks73 commented May 10, 2018

Fixed as of 075b6cc

@volks73 volks73 closed this as completed May 10, 2018
@fschutt
Copy link
Author

fschutt commented May 17, 2018

@volks73 You should maybe add that you have to add the %WIX%\bin directory to the %PATH.

So I had to add: C:\Program Files (x86)\WiX Toolset v3.11\bin to the PATH environment variable. You don't actually need the VS developer console to run Wix, I ran it from the git bash and it ran fine.

@fschutt
Copy link
Author

fschutt commented May 17, 2018

Or do this automatically (checking if %WIX% exists and adding it to the %PATH% if it isn't already present there).

@volks73
Copy link
Owner

volks73 commented May 17, 2018

@volks73 You should maybe add that you have to add the %WIX%\bin directory to the %PATH.

This is mentioned in the Installation section of the README:

Note, the WiX Toolset bin folder must be added to the PATH system environment variable for the cargo wix subcommand to work properly. The default location for the WiX Toolset bin folder is: C:\Program Files (x86)\WiX Toolset\bin or C:\Program Files (x86)\Wix Toolset v3.11\bin. Please add this path to the PATH system environment variable before using this cargo subcommand.

But I have changed the wording and structure to (hopefully) be more clear.

You don't actually need the VS developer console to run Wix, I ran it from the git bash and it ran fine.

I have added information under the Usage section to the README about being able to use git bash along with any other console/prompt/terminal. I have also changed the structure to be more clear that the VS developer console is not required but recommended. Using the VS developer console is recommended because it will add the signtool application to the PATH automatically if signing the installer.

@volks73
Copy link
Owner

volks73 commented May 17, 2018

Or do this automatically (checking if %WIX% exists and adding it to the %PATH% if it isn't already present there).

I would hesitate to have this sub-command manipulate system environment variables. Adding a path to the PATH system environment variable should be left to an installer or admin user.

However, this sub-command does use the WIX_PATH environment variable. If the -B,--bin-path option is not used, this sub-command will look for the WIX_PATH environment variable to find the compiler (candle.exe) and linker (light.exe). If the WIX_PATH environment variable is not found, this sub-command falls back to use the PATH system environment variable, and if that fails, a better error message is now displayed indicating these various options for pointing this sub-command to the WiX binaries are available.

I did notice documentation on the WIX_PATH environment variable is missing from the sub-commands CLI help (--help), so I created a separate issue (#51) to track adding documentation about the WIX_PATH environment variable to the help.

volks73 added a commit that referenced this issue Sep 3, 2019
This required changing the implementation of creating test projects. The `.tmp`
prefix can be used in Windows but the cargo project name cannot. Thus, the
`--name <NAME>` option needed to be used for creating a test package because the
`TempDir` type from the assert_fs package does not support the tempfile TempDir
builder or changing the prefix in newer versions. See Issues [#46] and [#48]
from the `assert_fs` project for more information.

[#46]: assert-rs/assert_fs#46
[#48]: assert-rs/assert_fs#48
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants