Is it possible to use wild card versions for dotnet global/local tools?

655 Views Asked by At

We use the normal dotnet-tools.json for setting up our dotnet local tools for our project but was wondering if there is a way to use wild card versions for the version numbers like you can do within csprojs with package references?

<PackageReference Include="Microsoft.EntityFrameworkCore.Tools" Version="5.0.0-rc.1.*" />

I've tried changing the dotnet-tools.json to the following:

{
  "version": 1,
  "isRoot": true,
  "tools": {
    "dotnet-ef": {
      "version": "5.0.0-rc.1.*",
      "commands": [
        "dotnet-ef"
      ]
    }
  }
}

However running dotnet tool restore gives the following error

Invalid manifest file. Path C:\dev\x\x.api\.config\dotnet-tools.json:
        In package dotnet-ef:
                Version 5.0.0-rc.1.* is invalid.
3

There are 3 best solutions below

0
On BEST ANSWER

Locating where error message originated in code, you can see that the version parsing is done by NugetVersion.TryParse which only allow semver-strings.
So it isn't possible to add wildcards.

1
On

Update for 2023:

I just discovered dotnet tool install does accept wildcards. To pin your dotnet-ef version to EF7 for example you can use dotnet tool install -g dotnet-ef --version 7.* and it will install the most recent 7.x version. I tested this with both the .Net 7 and 8 sdk's.

0
On

In my understanding, .config\dotnet-tools.json really contains definitions of what tool version to actually use, so it can't have wildcards. It is similar in concept to npm package-lock.json, to find a similar concept in another framework. Unless they decide to introduce a similar semantics for dotnet-tools.json in the future, where you can specify wildcards with semantic versioning, and then a lock file is produced separately, then you are left to use other approaches:

  • From the command line, you can manually update your package dotnet tool install or dotnet tool update, specifying a wildcard as suggested by @Joren;
  • You can avoid relying in a dotnet-tools.json at all, which is now my current approach in a project, and always install latest (or a controlled one with wildcards) version of a tool from the command line, and create dotnet-tools.json whenmissing with dotnet tool install MyTool --create-manifest-if-needed as documented.