dotnet tool install fails when there are multiple .csproj files in directory

[logankp]

Steps to reproduce

• Have multiple .csproj files in directory
• Run "dotnet tool install package --version version -g"

Expected behavior

Tool installs correctly.

Actual behavior

Tool install fails with the following error: "Specify which project file to use because this '/sln' contains more than one project file."

Environment data

.NET Core SDK (reflecting any global.json): Version: 2.1.302 Commit: 9048955601

Runtime Environment: OS Name: debian OS Version: 9 OS Platform: Linux RID: debian.9-x64 Base Path: /usr/share/dotnet/sdk/2.1.302/

Host (useful for support): Version: 2.1.2 Commit: 811c3ce6c0

.NET Core SDKs installed: 2.1.302 [/usr/share/dotnet/sdk]

.NET Core runtimes installed: Microsoft.AspNetCore.All 2.1.2 [/usr/share/dotnet/shared/Microsoft.AspNetCore.All] Microsoft.AspNetCore.App 2.1.2 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App] Microsoft.NETCore.App 2.1.2 [/usr/share/dotnet/shared/Microsoft.NETCore.App]

[fbouteruche]

It is the same issue if you want to run a global tool in a folder that contains multiple project files.

[JimSuplizio]

I also ran into this issue. I'm installing a tool that's published to one of our dev feeds, on Linux, in a repository that happens to have .proj files (note: it isn't just csproj, it's also .proj) at the root. I was able to get around this by setting the working directory to one that doesn't have any proj files in it but this seems wrong, considering it's only installing and not building. As stated above, this works fine on Windows, it only seems to be Linux and Mac.

[brunzefb]

I ran into this -- pretty annoying. Had to rename the other csproj.

[genriquez]

Hitting this issue as well in both windows and linux when trying to run a global tool. Only workaround that we can apply in our scenario is restructuring our repository. Since we are running a non-project specific command (the tool is globally installed), there should be no need for the project files in the working directory to affect how the command executes.

Repro steps

Can very easily repro by running the following commands on a bash terminal:

mkdir test
cd test
touch proj1.csproj
touch proj2.csproj
dotnet sometool

sometool being installed or not doesn't matter The command seems to fail even before that's checked.

Environment

• WSL: dotnet 7.0.119
• Windows: dotnet 8.0.400

[KalleOlaviNiemitalo]

@genriquez if you're trying to run a global tool, why are you using dotnet sometool? Shouldn't that be just sometool without dotnet?

[fadookie]

@KalleOlaviNiemitalo I am not very familiar with dotnet CLI but I was trying to follow the global tool install instructions for this tool: https://www.nuget.org/packages/CycloneDX/ It says to run this command:

dotnet tool install --global CycloneDX --version 4.0.0

But the command fails because I have multiple .csproj files in my project. How else am I supposed to install this tool? It's not documented.

[KalleOlaviNiemitalo]

@fadookie, my comment was addressed to @genriquez, who had already installed a global tool and was trying to run it.

[brunzefb]

Here is a bash script that shows how to do this. It will uninstall an older version, and then reinstall the specified version.

#!/bin/bash -e
VERSION=4.0.0
FEED=http://[REDACTED]/nuget/Tools/
NUGET_PACKAGE=CycloneDX
dotnet tool uninstall --global $NUGET_PACKAGE || true
dotnet tool install --global --version $VERSION --add-source $FEED $NUGET_PACKAGE

[genriquez]

@KalleOlaviNiemitalo the tool command is set as dotnet-sometool in the tool project, which is then packaged and published. This let's you run it as dotnet sometool. We actually don't want to care if the tool is local or global in our pipelines, or if it is in our PATH or not, so we rather run it through dotnet instead of calling it directly.

[juarola]

Faced this building a docker image in ci pipeline today, but with 2 dcproj files instead of csproj or proj. "Fixed" by switching to another dir for running dotnet tool install, and then returning to the sln root dir for the rest of the process, which seems a bit silly to me ;-)