Can't restore a DotNetCliToolReference for a tools package that targets netcoreapp1.1

[danroth27]

I was playing around with creating a .NET CLI tool. I created a .NET Core console app that targets netcoreapp1.1, because there are APIs in 1.1 that I wanted to use. When I added my package as a DotNetCliToolReference in a project I get the following error when restoring:

C:\Program Files\dotnet\sdk\1.0.0-rc3-004517\NuGet.targets(97,5): error : Package dotnet-toolbox 1.0.0-alpha-0001 is not compatible with netcoreapp1.0 (.NETCoreApp,Version=v1.0). Package dotnet-toolbox 1.0.0-alpha-0001 supports: netcoreapp1.1 (.NETCoreApp,Version=v1.1) [C:\Users\daroth\AppData\Local\Temp\2c239e15-0209-46df-9ccb-0116bdadd2a5\temp.csproj]
C:\Program Files\dotnet\sdk\1.0.0-rc3-004517\NuGet.targets(97,5): error : One or more packages are incompatible with .NETCoreApp,Version=v1.0. [C:\Users\daroth\AppData\Local\Temp\2c239e15-0209-46df-9ccb-0116bdadd2a5\temp.csproj] 

I'd like to be able to build a tool that targets netcoreapp1.1, but apparently I can only target netcoreapp1.0?

[mishra14]

Further discussion going on through email.

[natemcmaster]

This was requested before and closed "by design". See https://github.com/dotnet/cli/issues/4764#issuecomment-261331122. Current design is to add the 'prefercliruntime' file to your tool and target netcoreapp1.0.

there are APIs in 1.1 that I wanted to use.

When we made this choice, though we didn't consider this. Which APIs do you need that are not availabe on netcoreapp1.0 ?

[danroth27]

For example, I had wanted to use the 1.1.0 version of https://www.nuget.org/packages/Microsoft.Extensions.CommandLineUtils for my tool. Technically to stay in a supported configuration this package should be used with .NET Core 1.1. Targeting netcoreapp1.0 actually works, but isn't technically a supported configuration.

[natemcmaster]

The unfortunate state of .NET Core CLI tools is that you have to do jump through all sorts of hoops to make .NET Core 1.1 stuff work. The simplest solution for this specific case is to just use 'netcoreapp1.0' tfm with 1.1 packages.

[danroth27]

Sure, but I don't think we should get too caught up in my particular case. .NET Core will continue to add new features and surface area. You should be able to use those new APIs from a .NET Core tool and be clear in your tool package about that dependency. Doesn't the current behavior prevent that?

[natemcmaster]

Yup. And that will be addressed in 2.0. But for the 1.0.0 release, CLI tools are required to be 'netcoreapp1.0'.

[rrelyea]

Sounds like we should consider enabling this post-rtm

[natemcmaster]

Ping @rrelyea @blackdwarf - what is the plan for .NET Core (CLI) 2.0 tools?

/Users/namc/.dotnet/sdk/2.0.0-preview1-005418/NuGet.targets(97,5): error : Package Microsoft.DotNet.Watcher.Tools 2.0.0-preview
1-t0042651c7 is not compatible with netcoreapp1.0 (.NETCoreApp,Version=v1.0).

cc @livarcocc @piotrpMSFT

[blackdwarf]

@natemcmaster well, honestly, the latest I know is that we will not invest that much into them in 2.0 timeframe. So, basically, what we have today is what will be there.

[natemcmaster]

This is confusing. Seems like we should align with the "2.0" wave.

.NET Core runtime = 2.0
.NET Core CLI = 2.0
.NET Core CLI project tool = netcoreapp1.0

[blackdwarf]

@natemcmaster sorry, I'm confused. I thought you were asking about general improvements and upgrades in lieu of what we discussed a month or so back?

[natemcmaster]

Let me clarify, in .NET Core CLI 2.0, can a DotNetCliToolReference package target "netcoreapp2.0"? At the moment, NuGet will only restore a DotNetCliToolReference package if it targets netcoreapp1.0.

[livarcocc]

@natemcmaster Yes. we need to figure out a story to move these tools forward. I am trying to see if there is any drawbacks to make NuGet restore for 2.0 instead. I still don't think this is a definitive answer, as we will have to do it again on 3.0, but it may be all we can do in time for 2.0.

Basically, if we do this, it would mean that older version of the tools would not work with CLI 2.0, because they would fail to restore.

[natemcmaster]

👀 @mlorbetske

[rrelyea]

This is fixed in CLI 2 preview 2 and in VS 15.3 Preview 3 - build 26526.00 and later.

[rrelyea]

We had one "hack" fix for preview 1.

The fix we ended up with was:
SDK/CLI sets an msbuild property and passes it to nuget via dotnet restore command line param.
In VS, we also have the Roslyn project system sent that same property into NuGet when a restore is nominated.