Run dotnet local tool (if exists), fallback to global tool (if exists)

[augustoproiete]

Hi everyone. Does anyone have a good strategy to execute dotnet tools with Cake, in a way that it works regardless of how the tool was installed (local or global) - however giving priority to the local tool (if one exists)?

The issue I'm trying to workaround is the fact that if a dotnet tool is called Hello (without the dotnet prefix) then:

• If installed as a local tool, I must run dotnet Hello or dotnet run tool Hello for it to work
• If installed as a global tool, I must run Hello for it to work (as dotnet Hello doesn't work)

I know I can use context.Tools.Resolve("...") to resolve the global tool and find the shim, but is there a clever way to resolve the local tool first?

So far, I considered:

• 😞 Running dotnet tool list and parsing the result, in an attempt to detect if the local tool is there
• 🤢 Running dotnet Hello on a try/catch, and if it doesn't work assume local tool is not there, and try Hello next
• 🙅‍♂️ Parsing the .config\dotnet-tools.json and look for Hello in the commands (probably a bad idea as I can't guarantee the working dir is the same dir where the tool manifest is...)

I'm not particularly happy with any of these options if I'm honest, as they all seem hacky to me 😕

Any ideas?

[gep13]

@augustoproiete have you seen the Cake.DotNetTool.Module`? https://github.com/cake-contrib/Cake.DotNetTool.Module

This will allow you to express that a tool should be installed in the same way as an addin or NuGet tool, for example:

#tool dotnet:?package=Octopus.DotNet.Cli&version=4.41.0

You can specify whether it should be installed globally or not, along with other options, using parameters:

https://cake-contrib.github.io/Cake.DotNetTool.Module/docs/usage/parameters

This would allow you to directly control what, and how, tools should be installed.

Does this help?

One thing to note, if you do make use of this, and you are using 0.38.5 or earlier of Cake, you will need to execute the bootstrap option when running Cake to make sure that this Module is loaded correctly. However, if you are using the RC version of Cake 1.0.0, you don't need to do this.

[augustoproiete]

Thanks @gep13.

Unfortunately I don't think Cake.DotNetTool.Module is an option for me - correct me if I'm wrong.

One small (but important) detail I omitted in my question above is that I'm running a dotnet tool from a Cake plugin that targets Cake >= 0.33.0. I don't even know if I could use Cake.DotNetTool.Module from a Cake plugin, but even if I could, I imagine that my plugin would break for most (if not all) existing users of the plugin, as they would have to execute the bootstrap themselves (?).

I think some time from now once Cake 1.0.0 becomes mainstream, and I can drop support for Cake < 1.0.0, Cake.DotNetTool.Module might be an option then.

[gep13]

@augustoproiete can you elaborate on what you mean by Cake Plugin? I just want to make sure that we are talking about the same thing here.

The Cake.DotNetTool.Module is compiled against 0.33.0 (https://github.com/cake-contrib/Cake.DotNetTool.Module/blob/develop/Source/Cake.DotNetTool.Module/Cake.DotNetTool.Module.csproj#L15) so there should be no reason that you can't make use of it. It doesn't require that you have to use Cake.Tool in order to use it. You can absolutely run this Module using Cake.exe.

[augustoproiete]

@gep13 haha I meant Cake Add-In... Plugin/Add-In, Tomayto/Tomahto 😄 😄

I have a Cake Add-In that leverages DotNetCoreTool<TSettings> to run a dotnet tool that is assumed to be installed by the user, very similar to how Cake.DotNetCoreEf works... It takes care of running dotnet ef from a Cake script given that you have the tool already installed.

In this workflow we expect the user of the Cake add-in to have installed the dotnet tool in advance (local or global) e.g.:

dotnet tool install --global dotnet-ef

build.cake

#addin "nuget:?package=Cake.DotNetCoreEf&version=0.10.0"

DotNetCoreEfDatabaseUpdate("Database.csproj");

Luckily for Cake.DotNetCoreEf, the dotnet-ef tool uses the dotnet- prefix for the command, which is why it can be resolved as a local tool or global tool by the exact same command dotnet ef... I unfortunately don't have the same luck and the tool that I run doesn't use the prefix.

---

Re: Cake.DotNetTool.Module

Given the above, I would prefer not to force the developer writing the Cake script / using my Cake Add-in to have to use Cake.DotNetTool.Module to install the dotnet tool that my plugin runs (though they can if they want to, of course).

The way that Cake.DotNetTool.Module determines if a tool is installed or not is exactly what I classified as ":disappointed:" above in my initial message: Run dotnet tool list and parse the contents - which I was hoping to avoid.

So in the end I guess you did answer my question and it doesn't seem to be a better way to check if a local tool is installed, other than running dotnet tool list and parsing the contents.

Thanks for the help. I very much appreciate the ideas!

[gep13]

From my point of view, if an external tool is "required" in order for the build to work, then the build automation (when possible) should be responsible for installing that tool. In the case of .Net Global Tools, since you can install them to a local path using the Cake.DotNetTool.Module, this means that different projects can be working with different versions of the tools in isolation. Checking for globally installed tools, while useful, might actually cause problems if a new version is installed which then breaks another project. Just my thoughts on this.

[gep13]

There is a .Net Global Tool which can help with locating outdated .Net Global Tools https://github.com/dotnet-outdated/dotnet-outdated, which might be of some use to you.

[augustoproiete]

Cheers @gep13. 100% agreed. I also prefer dotnet tools to be installed as local tools together with the build script(s) that rely on it (and version controlled together) so that you can pin the version of the tool you depend on rather than depending on a global tool that is shared with other projects and can be upgraded, and that's what I recommend to the users of my Cake add-in, but... Some users of my add-in prefer to have the tool installed as a global tool and I want support that scenario as well in a seamless way, so that It Just Works™ - i.e. prefer local tool and use it if it's there, fallback to global tool if local tool not installed.

Thanks for the tip on the .NET Global Tools Outdated tool (I think you meant https://github.com/rychlym/dotnet-tools-outdated). I checked this tool as I was trying to figure this out and they check global tools only (by enumerating the folders in ~\.dotnet\tools\.store), not local tools.

I'm hoping that Microsoft will improve this in the future and give us a consistent way of running dotnet tools without knowing if they are local or global. i.e. dotnet <toolName> should always work and be resolved to the tool closest to the project (even if the command name doesn't have the dotnet- prefix).

[gep13]

Doh, sorry, yes, that is the tool I meant 😄