Global tool in Linux Docker container cannot be resolved

[JuergenRB]

I have a GitLab pipeline / Dockerfile in which a Linux image is loaded. [mcr.microsoft.com/dotnet/sdk:6.0-alpine]

In this image I run cake which installs a tool globally. This cannot be resolved within the cake script.

#tool dotnet:?package=Microsoft.Web.LibraryManager.Cli&version=2.1.175&global

var target = Argument("target", "LibMan");

Task("LibMan")
.Does(() => {
    FilePath libman = Context.Tools.Resolve(new string[]{ "libman.exe", "libman"}); 
    StartProcess(libman, new ProcessSettings { Arguments = new ProcessArgumentBuilder().Append("--version")});
});

RunTarget(target);

Adding ENV PATH="$PATH:/root/.dotnet/tools" before the dotnet cake call does solve the problem.

FROM mcr.microsoft.com/dotnet/sdk:6.0-alpine AS base
WORKDIR /app
COPY . .
RUN dotnet tool restore
ENV PATH="$PATH:/root/.dotnet/tools"
RUN dotnet cake

I wonder if it is the right way to go, especially since in DotNetToolContentResolver the path to the tools is resolved via ENV:HOME in Linux.
Maybe I am missing something ?

[nils-a]

@JuergenRB You are right in some ways: The DotNetToolResolver resolves $HOME/.dotnet/tools (on unix) automatically, but only lists the "real" dlls that are shipped in the nupkg.

The code you referenced:

cake/src/Cake.DotNetTool.Module/DotNetToolContentResolver.cs

Line 69 in 9828d7b

return GetToolFiles(new DirectoryPath(_environment.GetEnvironmentVariable("HOME")).Combine(".dotnet/tools"), package);

"augments" the directory some lines further down:

cake/src/Cake.DotNetTool.Module/DotNetToolContentResolver.cs

Line 88 in 9828d7b

var toolFolder = installationLocation.Combine(".store/" + package.Package.ToLowerInvariant());

And then gets the dlls from there:

cake/src/Cake.DotNetTool.Module/DotNetToolContentResolver.cs

Lines 110 to 111 in 9828d7b

	// Get default files (dll).
	patterns = patterns ?? new[] { path.FullPath + "/**/*.dll" };

However, your code searches for "libman.exe", "libman" which are the shims generated automatically by dotnet. Those are not generated in the .store/PACKAGENAME folder, but rather directly in the .dotnet/tools folder.

Now, while $HOME/.dotnet/tools should be added to your PATH on first usage of dotnet tool, this feature is known to be somewhat buggy.

So, yes, adding the .dotnet/tools folder manually to the PATH would be the correct way to ensure this is working.