Sdk: invoke a dotnet tool with multiple *proj in same directory is not possibile

[enricosada]

Steps to reproduce

Or:

• download https://github.com/dotnet/netcorecli-fsc/tree/eb4a2943518e7c188c6e33939246158623d679e0/test-msbuild/TestMultipleLibraryInSameDir
• dotnet restore Test1Library.fsproj ok
• dotnet restore Test2Library.fsproj ok
• dotnet compile-fsc fails

Or:

• inside a directory
  
  
  
  • create a lib with name lib1.csproj
  
  
  • create a lib with name lib2.csproj
  
  
• Add any tool (for example dotnet-mytool) inside one or both projects
• dotnet restore lib1.csproj works
• dotnet restore lib2.csproj works
• dotnet mytool fails

Expected behavior

It's possibile like with dotnet restore to invoke the tool command somehow.
The dotnet mytool should fail only if ambiguous (both lib project define mytool), otherwise should work (best experience).
But expecit passing the project name maybe, like dotnet -p lib1.csproj mytool should make the tool work

I think the issue is because the old project.json was one for directory, so the check to resolve the project to use was ok.

Actual behavior

Error:

Specify which project file to use because this 'e:\repro' contains more than one project file.

Environment data

.NET Command Line Tools (1.0.0-preview3-004056)

Product Information:
 Version:            1.0.0-preview3-004056
 Commit SHA-1 hash:  ccc4968bc3

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.14393
 OS Platform: Windows
 RID:         win10-x64

ref https://github.com/dotnet/netcorecli-fsc/issues/47

[TheRealPiotrP]

I do agree that we can do magic here to figure out how to function in a directory with multiple proj files. However, based on our previous conversations, I expect that what we really want is for the solution to have a command version that is global to the solution/repo. Is that fair? Is it at least the right prioritization?

[enricosada]

command version that is global to the solution/repo. Is that fair? Is it at least the right prioritization?

Yes, i think so. tools usually are shared per repo or global, that's the best ihmo.
This one is just a minor corner case

[natemcmaster]

:+1: for global installation of CLI tools, but in the meantime, is there any good workaround? I haven't found one other than renaming all but one .csproj file.

[qmfrederik]

I wanted to chime in and check whether there's a workaround for this issue?

I just hit this as well, when trying my shiny new dotnet zip/dotnet tarball/dotnet rpm commands :).

In my case, I'm not sure whether I want the tool to be installed globally - I'm guessing that could create some issues in shared build environments?

Also, I only expect to invoke this command for the project in my solution that delivers the final executable - not the assemblies.

Net, in my use case, I'd prefer to keep the tool at the project level instead of solution/global.

Here's the environment info:

.NET Command Line Tools (2.0.0-preview1-005977)

Product Information:
 Version:            2.0.0-preview1-005977
 Commit SHA-1 hash:  414cab8a0b

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.15063
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   C:\Program Files\dotnet\sdk\2.0.0-preview1-005977\

Microsoft .NET Core Shared Framework Host

  Version  : 2.0.0-preview1-002111-00
  Build    : 1ff021936263d492539399688f46fd3827169983

[angularsen]

Can we add a project parameter?

Something like this:
dotnet xunit TestProject.NetCore.csproj
dotnet xunit TestProject.WindowRuntimeComponent.csproj

I have a dir with two test projects (to test same source with two different conditional compilation symbols).

Related:
https://github.com/dotnet/cli/issues/6267
https://github.com/xunit/xunit/issues/1360

[helloserve]

I might also add that it's not just multiple .csproj and/or .sln files that causes this behavior. I had a .csproj and a .dcproj file in my folder, and it wouldn't run until I deleted the docker project file also.

[sdekock]

We have issues with this on our buildserver (TeamCity) and the .metaproj files that are generated by the MSBuild ASP.NET Core tooling.
Could you make the dotnet cli ignore the .metaproj file?

[ViktorHofer]

This is causing trouble in corefx when runnin on Unix:

Specify which project file to use because this '/home/vihofer/.nuget/packages/microsoft.dotnet.arcade.sdk/1.0.0-beta.18603.8/tools' contains more than one project file.
  Usage: dotnet tool install [options] <PACKAGE_ID>

/home/vihofer/corefx/eng/Tools.props(90,5): warning MSB3073: The command "/home/vihofer/corefx/.dotnet/dotnet tool install --tool-path /home/vihofer/corefx/artifacts/tools/ coverlet.console --version 1.3.0 --add-source https://api.nuget.org/v3/index.json" exited with code 1. [/home/vihofer/.nuget/packages/microsoft.dotnet.arcade.sdk/1.0.0-beta.18603.8/tools/Tools.proj]

Any viable workaround at this point?

[tfmeneses]

This works for me:

dotnet publish TripTravel.sln -c Release -o published

[benmccallum]

Somehow this isn't an issue for me locally but is when used in a dockerfile. Super confused. My machine has the 3.0.100 SDK whereas I'm in a docker container using the 2.2 SDK image. Could this be fixed in 3.0? Can anyone else confirm?

Update: For kicks I changed the image to 3.0 one and it didn't change anything. Same error.

[redoz]

I just got bit by this, has anyone found a work-around yet?