-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Unexpected pickup of old runtime version for tool package #16148
Comments
I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label. |
This happens with every such tool package. I've just upgraded another tool from netcoreapp2.0 to netcoreapp3.1 and it results in the very same error message. I cannot build my project anymore! Everything is checked, I uninstalled the packages, deleted the files from ~/.nuget/packages and installed and restored the packages again. Same error. Something in Visual Studio or the CLI doesn't like .NET Core 3.1 but still wants me to stick woth .NET Core 2.0. It's frustrating. |
I have now uninstalled the .NET Core 2.1 and 2.2 SDKs and runtimes from my computer. They no longer appear in the output of Deleting all NuGet caches through the package manager settings UI in Visual Studio also doesn't help. The error comes back immediately on restoring packages. |
Here's a very simple sample app that I put together in a few minutes. It reproduces the trouble very quickly. The CliTool project is the one that generates the tool package. Its build output is included in the archive but you can rebuild it. Put the nupkg file in a directory that you have configured as NuGet package source on your local machine. (You need that anyway when working with your own packages.) The CliToolConsumer project then uses that project. It won't build as you'll see. Seems the dotnet CLI isn't production ready and needs to be fixed urgently! Strange that nobody noticed that yet. Am I the first user of it, again? |
This seems to be the root of the trouble. I'm going to have to look into whatever replaces this mechanism and see if it's a replacement at all or if I'll have to fall back to the good old ToolSetup.exe to be installed on every developer and build machine, together with the .NET build tools, like we've done it the past 30 years. |
Yes, local tools are the replacement for |
I have installed these runtime versions: 2.1, 2.2, 3.1, 5.0
When I install this package into a project that targets netcoreapp3.1 and try to restore packages with
dotnet restore
, I get this error output:This also leads to more errors of the same kind later so it breaks my build.
The DotnetSshDeploy package has been upgraded from 0.3.1 to 0.4.0, that's the only change. And that tool now targets both netcoreapp3.1 and net5.0 instead of netcoreapp2.0. That's probably the major change in that package. But nobody uses or references .NET Core 2.2 (anymore)! I've deleted all build files and the .vs directory, then searched the contents of all files in the solution for "netcoreapp2.2" – no matches at all. Yet this error occurs. Something seems to stick with the old runtime version even though it's not configured anymore. Should I uninstall that version from my computer? (Some other older projects might still need it.)
What makes the dotnet CLI think that an old version should be used what nobody told it so?
dotnet --info
:The text was updated successfully, but these errors were encountered: