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

Add support for using paket as a .NET Core 3 local tool #3660

Closed
tboby opened this issue Sep 23, 2019 · 7 comments · Fixed by #3668

Comments

@tboby
Copy link

commented Sep 23, 2019

Description

.NET Core 3 adds support for repository specific tools that are restored with the correct version for your platform. These are defined in a manifest called dotnet-tools.json, a lockfile for dotnet "local" tools.

This removes the need to commit paket.exe, removes the need for mono, and generally makes it really easy to install paket.

Paket can be defined as a dependency in this way, correctly restores, and can be manually run using dotnet paket or dotnet tool run paket.

However, Paket.Restore.targets does not seem to know about local tools.

Repro steps

  1. clone https://github.com/tboby/paket-local-tool-sample

  2. dotnet tool restore

  3. cd src

  4. dotnet build

Expected behavior

The project should trigger a paket restore, then build.

Actual behavior

  '"paket.exe"' is not recognized as an internal or external command,
  operable program or batch file.
C:\Users\Thomas\Git\paket-local-tool-sample\.paket\Paket.Restore.targets(138,5): error MSB3073: The command ""paket.exe" restore" exited with code 9009. [C:\Users\Thomas\Git\paket-local-tool-sample\src\paket-local-tool-sample.fsproj]

Known workarounds

Add <PaketCommand>dotnet paket</PaketCommand> to the project file.

@forki

This comment has been minimized.

Copy link
Member

commented Sep 23, 2019

@tboby

This comment has been minimized.

Copy link
Author

commented Sep 24, 2019

As far as I can tell msbuild doesn't know about local tools, and the path to the local tool probably isn't consistent (e.g. C:\Users\tboby\.dotnet\toolResolverCache\1\paket.
Would it be a reasonable approach to try to use an Exec task to run the local tool, and use the exit code to determine if it's available?

@kjohnphillip

This comment has been minimized.

Copy link

commented Sep 26, 2019

It appears that PaketCommand in Paket.Restore.targets is missing the case for Paket as a local tool i.e. when PaketExePath does not have an extension. Inserting the following line temporarily fixes the issue, until that file is overwritten:
<PaketCommand Condition=" '$(PaketCommand)' == '' AND '$(_PaketExeExtension)' == '' ">dotnet "$(PaketExePath)"</PaketCommand>

I'm happy to create a PR for this if anyone can point me towards where best to extend any tests that cover the state of that file.

@atlemann

This comment has been minimized.

Copy link
Contributor

commented Sep 27, 2019

Was just about to try this and hit the same issue and can confirm adding that line, @kjohnphillip, works on my linux machine (if you haven't already checked that).

@forki

This comment has been minimized.

Copy link
Member

commented Sep 27, 2019

Please send PR

@atlemann

This comment has been minimized.

Copy link
Contributor

commented Sep 27, 2019

I have just tested on my linux box though and am wondering the same as above if there are any tests or for changes like this.

@forki

This comment has been minimized.

Copy link
Member

commented Sep 27, 2019

no we don't have tests for targets files.

@forki forki closed this in #3668 Sep 27, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.