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

Tool helper utilities should allow for dotnet cli, global and local tools #2398

Closed
SteveGilham opened this issue Sep 28, 2019 · 2 comments · Fixed by #2399
Closed

Tool helper utilities should allow for dotnet cli, global and local tools #2398

SteveGilham opened this issue Sep 28, 2019 · 2 comments · Fixed by #2399

Comments

@SteveGilham
Copy link
Contributor

SteveGilham commented Sep 28, 2019

Description

Some traditional .net framework tools now offer dotnet CLI or global tool variants (and with .net core 3.0, those global tools can be installed as local ones), but where Fake offers helper classes, those still assume traditional framework .exe files.

Repro steps

In a project, create a .config/dotnet-tools.json like

{
  "version": 1,
  "isRoot": true,
  "tools": {
    "dotnet-reportgenerator-globaltool": {
      "version": "4.2.20",
      "commands": [
        "reportgenerator"
      ]
    }
  }
}

With .net core 3.0, run dotnet tool restore

At the command line, you can run dotnet reportgenerator, but the Fake.Testing.ReportGenerator.ReportGeneratorParams type has no way to accept that.

Expected behavior

An indicator type (probably in a core module) like
type ToolType = DotNet of string | Global | Framework

and an extra .ToolType field in the Params type, defaulting to ToolType.Framework, but when overridden would ignore the .ExePath and execute dotnet [toolname] or [toolname] for ToolType.DotNet (cli and local tool variants, with the string there to allow for possible tool name differences) and ToolType.Global respectively.

Consideration might be given to deprecating .ExePath and defining ... | Framework of String instead, with any non null-or-empty string overriding .ExePath

Actual behavior/Known workarounds

I need to use a raw command executor and roll my own arguments as "dotnet reportgenerator" isn't a valid .ExePath, and the global reportgenerator would be mono-ified on non-Windows platforms

Related information

  • Operating system -- any
  • Branch -- as released
  • .NET Runtime, CoreCLR or Mono Version
  • Indications of severity -- mainly an annoyance
  • Version of FAKE (4.X, 5.X) -- 5.16.1
  • (if performance issue) Performance information, links to performance testing scripts -- N/A
@TheAngryByrd
Copy link
Contributor

This is definitely an issue now that paket can be a local tool.

@matthid
Copy link
Member

matthid commented Oct 20, 2019

Will be available in the next release via #2399:

  • A low level helper CreateProcess.withToolType
  • A ToolType parameter for reportgenerator and paket

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants