-
Notifications
You must be signed in to change notification settings - Fork 252
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Can't restore a DotNetCliToolReference for a tools package that targets netcoreapp1.1 #4396
Comments
Further discussion going on through email. |
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.
When we made this choice, though we didn't consider this. Which APIs do you need that are not availabe on netcoreapp1.0 ? |
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. |
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. |
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? |
Yup. And that will be addressed in 2.0. But for the 1.0.0 release, CLI tools are required to be 'netcoreapp1.0'. |
Sounds like we should consider enabling this post-rtm |
Ping @rrelyea @blackdwarf - what is the plan for .NET Core (CLI) 2.0 tools?
cc @livarcocc @piotrpMSFT |
@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. |
This is confusing. Seems like we should align with the "2.0" wave. .NET Core runtime = 2.0 |
@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? |
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. |
@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. |
This is fixed in CLI 2 preview 2 and in VS 15.3 Preview 3 - build 26526.00 and later. |
We had one "hack" fix for preview 1. The fix we ended up with was: |
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:
I'd like to be able to build a tool that targets netcoreapp1.1, but apparently I can only target netcoreapp1.0?
The text was updated successfully, but these errors were encountered: