Skip to content
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

Closed
ygoe opened this issue Mar 1, 2021 · 6 comments
Closed

Unexpected pickup of old runtime version for tool package #16148

ygoe opened this issue Mar 1, 2021 · 6 comments
Assignees
Labels
untriaged Request triage from a team member

Comments

@ygoe
Copy link

ygoe commented Mar 1, 2021

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:

C:\Source\MyApp\MyApp.csproj : error NU1202: Das Paket Unclassified.DotnetSshDeploy 0.4.0 ist nicht mit netcoreapp2.2 (.NETCoreApp,Version=v2.2) kompatibel. Paket Unclassified.DotnetSshDeploy 0.4.0 unterstützt Folgendes: [C:\Source\MyApp\MyApp.sln]
C:\Source\MyApp\MyApp.csproj : error NU1202:   - net5.0 (.NETCoreApp,Version=v5.0) [C:\Source\MyApp\MyApp.sln]
C:\Source\MyApp\MyApp.csproj : error NU1202:   - netcoreapp3.1 (.NETCoreApp,Version=v3.1) [C:\Source\MyApp\MyApp.sln]

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:

.NET SDK (gemäß "global.json"):
 Version:   5.0.103
 Commit:    72dec52dbd

Laufzeitumgebung:
 OS Name:     Windows
 OS Version:  10.0.19041
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   C:\Program Files\dotnet\sdk\5.0.103\

Host (useful for support):
  Version: 5.0.3
  Commit:  c636bbdc8a

.NET SDKs installed:
  5.0.103 [C:\Program Files\dotnet\sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.All 2.1.25 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.All 2.2.8 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.App 2.1.25 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 2.2.8 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 3.1.12 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 5.0.3 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 2.1.25 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.2.8 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 3.1.12 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 5.0.3 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.WindowsDesktop.App 3.1.12 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 5.0.3 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

To install additional .NET runtimes or SDKs:
  https://aka.ms/dotnet-download
@dotnet-issue-labeler
Copy link

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.

@dotnet-issue-labeler dotnet-issue-labeler bot added the untriaged Request triage from a team member label Mar 1, 2021
@ygoe
Copy link
Author

ygoe commented Mar 2, 2021

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.

@ygoe
Copy link
Author

ygoe commented Mar 5, 2021

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 dotnet --info. Yet this error message persists. Something in Visual Studio, the dotnet CLI or whatever component must be hardwired to .NET Core 2.2. Nobody uses it, nobody knows it exists, it's not referenced anywhere. Really weird. Only happens with tool packages targeting .NET Core 3 or newer. I'm effectively unable to use tool packages, which includes that I'm unable to deploy application updates to any server system now (staging and production!).

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.

@ygoe
Copy link
Author

ygoe commented Mar 5, 2021

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?

CliTool.zip

@ygoe
Copy link
Author

ygoe commented Mar 9, 2021

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.

@dsplaisted
Copy link
Member

Yes, local tools are the replacement for DotNetCliToolReference. Here is the documentation: https://docs.microsoft.com/en-us/dotnet/core/tools/global-tools#install-a-local-tool

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
untriaged Request triage from a team member
Projects
None yet
Development

No branches or pull requests

2 participants