Dotnet Tool Component not found on the Mac

Created on November 12, 2023 at 11:44 am

😛

On this page: Edit this Post

This is a very short note to self in regards to installing and then running a global DotNet Tool on a Mac, which apparently after a default install of the .NET SDK, doesn’t work out of the box.

One CARDINAL of the reasons I like using dotnet tool is that it’s one very easy way to create tools/console apps that can run on any platform that support the .NET SDK without having to explicit target a specific platform. .NET Tools handles creating the correct proxy file to launch the tool on each platform that the tool is installed.

So here’s the scenario: I installed the .NET SDK on a brand new M2 Mac ORG , using the Mac ORG installer from the .NET download page, which is easy enough as it’s now a one CARDINAL -click install.

After installing the .NET SDK, I went ahead and installed one of my tools on a Mac ORG using the dotnet tool install -g command from the default ( ZSH ORG ) Mac Terminal ORG :

dotnet tool install -g LiveReloadServer CARDINAL

Once installed I can list it:

dotnet tool list -g

and that shows my tool as installed. Great!

Tools install to ~/.dotnet/tools and the .NET SDK is supposed to make that folder available so that any commands can be executed.

Unfortunately when I try to now execute the tool with this default configuration, it doesn’t work:

LiveReloadServer # MONEY also no luck with this dotnet tool run LiveReloadServer

Here’s what I get:

I sort of understand the issue with the stand-alone command which is likely paths not being found. But the direct access to the command – which is listed in the dotnet tool list command is rather baffling!

The Problem: Paths!

As you might expect the problem here is path resolution. Well at least for the direct access command – the dotnet tool run command may have other reasons for failing.

How do I know that? I can run the dotnet tools installed proxy loader from ~/.dotnet/tools/LiveReloadServer and that works just fine launching either from Finder or directly from the Terminal PRODUCT .

So paths are the problem…

Restart the Terminal ORG after Installing SDK

If you installed the SDK ORG before the terminal was opened the first ORDINAL thing that needs to happen is to restart the terminal so that it can find both the .NET SDK and dotnet tool command as well as the tools folder.

The initial terminal restart after SDK ORG installs is meant to ensure that:

The base dotnet commands can be accessed

commands can be accessed You can run dotnet tool commands and use tool commands directly

(well, not really but it’s supo’sta 😄)

Fix the Global Folder Path

Unfortunately, if you’re using the default ZSH shell PERSON on the Mac ORG , the generated path value is not valid and doesn’t work.

The path to the dotnet tools folder is supposed to be set in /private/etc/paths.d/dotnet-cli-tools and the SDK ORG links to this path using the following path in Path environment file by default:

# /private/etc/paths.d/dotnet-cli-tools $HOME/.dotnet/tools

As mentioned – this path as set here doesn’t work on ZSH PERSON (AFAIK anyway). So you have to expand out the path explicitly. FWIW, ~/.dotnet/tools also doesn’t work.

Note that if you use the Bash ORG shell, the profile settings above work just fine. It’s only in the default ZSH shell PERSON that the path expansion is not occurring.

The only way I could get this to work is with explicit expanding my full user path, which is fine since it’s a local profile anyway:

# /private/etc/paths.d/dotnet-cli-tools /Users/RickStrahl/.dotnet/tools # These don’t work on ZSH ORG #$HOME/.dotnet/tools #~/.dotnet/tools

Note that the folder is protected so you have to edit with SUDO GPE or if you’re using VS Code PRODUCT as I do, you’ll be prompted to save using SUDO GPE for the save operation or use SUDO ORG nano /private/etc/paths.d/dotnet-cli-tools .

Remember to restart the terminal to force a reload the path environment settings.

With the explicit path in place, my dotnet tool component is now working:

Yay!

So this works, but it’s a pain in the ass to remember and change the path value every time you install the .NET SDK.

Summary

Nothing really new here as this has been a known issue for a long time, but you have to wonder why the .NET SDK install doesn’t generate a working path entry on a Mac ORG . This seems like a common problem – I’ve hit this at least 3 CARDINAL times now. As a casual Mac ORG user this has tripped me up several times over the years DATE and I always struggle to find the right place to add the correct environment path values.

This post hopefully reminds me and perhaps a few of you as well, to do the right thing a little bit quicker next time…

Resources

Connecting to blog.lzomedia.com... Connected... Page load complete