I have created a test pipeline with a .NET Core Installer task like this:
Running the task today (2019-11-22), it installs v2.2.402:
##[section]Starting: Use .Net Core sdk 2.2.x
==============================================================================
Task : Use .NET Core
Description : Acquires a specific version of the .NET Core SDK from the internet or the local cache and adds it to the PATH. Use this task to change the version of .NET Core used in subsequent tasks. Additionally provides proxy support.
Version : 2.0.24
Author : Microsoft Corporation
Help : https://aka.ms/AA4xgy0
==============================================================================
Tool to install: .NET Core sdk version 2.2.x.
Found version 2.2.402 in channel 2.2 for user specified version spec: 2.2.x
Version: 2.2.402 was found in cache.
Creating global tool path and pre-pending to PATH.
##[section]Finishing: Use .Net Core sdk 2.2.x
According to the Download .NET Core 2.2 page, SDKs 2.2.402, 2.2.206 and 2.2.109 (runtime v2.2.7) were released on September 10th 2019:
But SDKs 2.2.207 and 2.2.110 (runtime v2.2.8) were released on November 19th 2019:
So, acccording to the documentation of the .NET Core Installer task, versions can be given in the following formats:
2.x => Install latest in major version.
2.2.x => Install latest in major and minor version
2.2.104 => Install exact version
Why was v2.2.402 installed? What is the criteria used for choosing the version of the SDK to install when using wildcards such as 2.2.x or 2.1.x?
The version in Use .Net Core task or .Net Core Installer task are picked using semantic versioning 2.0.
Hence, the highest version number is picked which in case of 2.2.207 and 2.2.402 is 2.2.402
Why was v2.2.402 installed? What is the criteria used for choosing the version of the SDK to install when using wildcards such as 2.2.x or 2.1.x?
Sorry for this late reply, but still hope it can give you any help
This is a known issue on Github:
.NET Core November Update - 2.1.14, 2.2.8, and 3.0.1
IanKemp commented:
2.2.7 contained SDK 2.2.402 for VS 2019 v16.2, but this release has no SDK for 16.2 only for 16.0. Does that mean SDK 2.2.402 is the latest
and that if we already have it, we don't need SDK 2.2.207 from 2.2.8
Compare the release note v2.2.8 and v2.2.7:
So, the latest SDK version does not support the latest Visual Studio version, that may the reason why we still get the version v2.2.402 by that task.
The version that supports 16.2 should be released soon. By then we can use this task to get version 2.2.207.
Hope this helps.
Related
Context
After migrating to version 3.1.420 of dotnetcore SDK (installed automatically by Windows Update) we are facing the problem, that a solution failed to build (on a build server) because nuget restore is unable to restore the package Microsoft.NETCore.App.Host.win-x64.
We have local package feeds configured in nuget.config, the source nuget.org is not and must not accessed directly!
Now I get the following output:
c:\> nuget.exe restore ***.sln -NoCache -NonInteractive -ConfigFile .nuget\NuGet.config
[...]
Errors in C:\build\_work\313\s\***.csproj
NU1101: Unable to find package Microsoft.NETCore.App.Host.win-x64. No packages exist with this id in source(s): ***, ***, ***
NuGet Config files used:
C:\build\_work\313\s\.nuget\NuGet.config
Feeds used:
https://***.com/tfs/***/_packaging/A***/nuget/v3/index.json
https://***.com/tfs/***/_packaging/B***/nuget/v3/index.json
https://***.com/tfs/***/_packaging/C***/nuget/v3/index.json
Environment:
C:\build\_work\313\s>dotnet --list-sdks
3.1.420 [C:\Program Files\dotnet\sdk]
5.0.400 [C:\Program Files\dotnet\sdk]
5.0.408 [C:\Program Files\dotnet\sdk]
Question
Why restore process tries to fetch the nuget package while the content is already part of the SDK installed?
What I've tried?
I've analyzed the behavior of the nuget.exe using Process Monitor (Sysinternals).
I found that the folder c:\Program Files\dotnet\packs\Microsoft.NETCore.App.Host.win-x64\3.1.25\ is accessed but not found, only the folder 3.1.26 exists after update of SDK.
Why restore process tries to access "3.1.25" while "3.1.26" is installed?
On my local machine the restore works as expected. The package is NOT available in my local NuGet cache. Here the folder c:\Program Files\dotnet\packs\Microsoft.NETCore.App.Host.win-x64\3.1.26\ is accessed as expected.
I also tried to reinstall the SDK version. No effect.
Firstly, I highly recommend avoiding nuget.exe restore. If you can, prefer dotnet restore, and otherwise msbuild -t:restore. It's unrelated to the problem you're having here, but you can avoid different types of problems by migrating.
Anyway, the .NET Core SDK 3.1.419 would have had the version 3.1.25 versions of the runtime host, whereas .NET Core SDK 3.1.420 has version 3.1.26 of the runtime hosts. Hence, when the SDK upgraded from 419 to 420, the old version of the runtime host was removed, and the new one installed.
However, as your dotnet --list-sdks output shows, you have the .NET 5 SDK installed. .NET 5 is now out of support, and so it did not receive any update in this month's Patch Tuesday. In May, the last month that the .NET 5 SDK was updated, the latest version of the .NET 3.1 hosting app package was 3.1.25, so when you restore/build an app targeting .NET Core 3.1 with the .NET 5 SDK, the SDK checks for the version of the runtime hosting package it knows about, sees it isn't available locally, and then tells NuGet to download it.
You can either use a global.json to pin that directory's dotnet commands to the .NET 3.1 SDK, or you can install the June 2022 .NET 6 SDK (6.0.301), and then both of them will know that the .NET 3.1 runtime hosting package is version 3.1.26, and therefore should not ask NuGet to download it. Well, unless you uninstall the .NET 3.1 SDK completely and use the .NET 6 SDK to build it.
I know it's confusing. The .NET marketing people chose names that doesn't aid in understanding the difference, but the .NET SDK are build tools that can build any version of .NET equal or lower version, and the .NET runtime is completely independent. As mentioned previously in this answer, you can build .NET Core 3.1 apps with the .NET 6 SDK, the .NET Core 3.1 SDK is not needed (but the runtime will be, unless you publish a "self-contained" app).
With the release of .NET Core 2.2 I expected to be able to build such projects in our Microsoft-hosted DevOps (Azure) pipeline. But the restore step fails, saying 2.2 is not supported:
2018-12-11T14:57:49.0856135Z "D:\a\1\s\My.Project\My.Project.csproj" (Restore target) (1) ->
2018-12-11T14:57:49.0857867Z "D:\a\1\s\MyProject.EntityFramework\MyProject.EntityFramework.csproj" (_GenerateRestoreGraphProjectEntry target) (2:3) ->
2018-12-11T14:57:49.0858029Z (_CheckForUnsupportedNETCoreVersion target) ->
2018-12-11T14:57:49.0858191Z C:\Program Files\dotnet\sdk\2.1.402\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.TargetFrameworkInference.targets(137,5): error NETSDK1045: The current .NET SDK does not support targeting .NET Core 2.2. Either target .NET Core 2.1 or lower, or use a version of the .NET SDK that supports .NET Core 2.2. [D:\a\1\s\MyProject.EntityFramework\MyProject.EntityFramework.csproj]
2018-12-11T14:57:49.0858287Z
2018-12-11T14:57:49.0858338Z
2018-12-11T14:57:49.0858398Z "D:\a\1\s\My.Project\My.Project.csproj" (Restore target) (1) ->
2018-12-11T14:57:49.0858504Z "D:\a\1\s\My.Project\My.Project.csproj" (_GenerateRestoreGraphProjectEntry target) (1:5) ->
2018-12-11T14:57:49.0858645Z C:\Program Files\dotnet\sdk\2.1.402\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.TargetFrameworkInference.targets(137,5): error NETSDK1045: The current .NET SDK does not support targeting .NET Core 2.2. Either target .NET Core 2.1 or lower, or use a version of the .NET SDK that supports .NET Core 2.2. [D:\a\1\s\My.Project\My.Project.csproj]
The project builds fine locally, so I think it is most likely that I'm missing something - especially as I come up with nothing on my internet search for similar errors.
Could it really be it is not supported yet?
OK, so there is a task ".NET Core Installer" that can be added before the Restore task, and by requesting 2.2.100 to be installed first of all the build passes.
This does trick to my project:
steps:
- task: DotNetCoreInstaller#0
displayName: 'Use .NET Core SDK Tool Installer'
inputs:
version: 2.2.100
- script: dotnet build --configuration $(buildConfiguration)
displayName: 'dotnet build $(buildConfiguration)'
I had the same problem with my pipeline. Here is the solution:
Add to your job (press plus button) in the pipeline task .NET Core SDK Installer. You can search for it in a search box
Make sure to put that task on the top of your job. You can use drag&drop.
Set up version of .Net Core SDK Installer at least the same your version.
You can see all available version by pressing on the "here" word the in the popup
The answer of #bit0001 is correct. Microsoft has a list of supported versions that can be installed using this task. You can find those versions here.
As you can see, 2.1.500 is supported when installing the sdk, 2.1.0 is not, you'll need to use 2.1.300. When installing only the runtime, you can use 2.1.0. Currently, the latest 2.2 version supported is 2.2.100.
Got this error today after upgrading VS2017 to v15.8.2 and trying to build my dotnet core project (target framework .NET Core 2.1):
Severity Code Description Project File Line Suppression State
Error NETSDK1061: The project was restored using
Microsoft.NETCore.App version 2.1.3, but with current settings,
version 2.1.3-servicing-26724-03 would be used instead. To resolve
this issue, make sure the same settings are used for restore and for
subsequent operations such as build or publish. Typically this issue
can occur if the RuntimeIdentifier property is set during build or
publish but not during restore. For more information, see
https://aka.ms/dotnet-runtime-patch-selection.
What to do?
Found out solution:
Uninstall .NET Core SDK 2.1.401, that came with vs2017 v15.8.2 and install it again using an installer from the .NET Downloads page.
Source: #joshuadavidson https://github.com/dotnet/cli/issues/9897
Also quote #peterhuene:
"It's come to my attention that VS 15.8.2 did not include the correct,
final build of the 2.1.401 SDK. We are working on resolving this
issue. In the meantime, uninstalling the 2.1.401 SDK installed by
Visual Studio and installing the SDK from the .NET Downloads site
should correct the issue."
Update, September 7th 2018:
or simply upgrade to VS2017 v15.8.3, where the problem is resolved:
"Visual Studio 2017 version 15.8.2 contained a pre-release build of
.NET Core SDK 2.1.401 that is incompatible with Visual Studio. We have
corrected this issue with Visual Studio 2017 version 15.8.3."
I'm confused about .NET Core and version numbers. I downloaded the .NET Core 1.1 Windows (x64) Installer (.exe). When the installer started to run, it says ".NET Core SDK 1.0.3 (x64) Setup". When I type "dotnet --version" from the command line, I also get "1.0.3".
Why doesn't the version information show "1.1"?
.NET Core Runtime (binaries) and .NET Core SDK have different versions and it's by design:
.NET Core Runtime and SDK download archive.
For example, .NET Core Runtime 1.1.1 is distributed together with SDK 1.0.3.
dotnet --version command returns latest SDK version.To check all SDK versions installed, go to
c:\program files\dotnet\sdk
At this moment, dotnet doesn't provide a console command to print Runtime versions. You can track a discussion about it at GitHub:
Add a CLI gesture to display installed SDKs/Runtimes in the host location.
Workaround (Windows)
It is possible to install multiple Runtime and SDK versions. To find all Runtimes installed, go to folder:
C:\Program Files\dotnet\shared\Microsoft.NETCore.App\
and check subfolders with installed Runtime binaries:
1.0.3
1.0.4
1.1.0
1.1.1
That is still actual for .NET Core 2.0 Preview 1.
The funny part is, the SDK is designed to be independent of the runtime i.e. The dotnet SDK is capable of running your app with different runtime versions, including .NET Framework (full framework) runtime. It's specified in your *.csproj (or *.fsproj)
<TargetFramework>netcoreapp1.1</TargetFramework>
So what happens is the SDK will look at that project file, and install the runtime if it's missing from your machine when you run dotnet restore.
You can get the current runtime version of the program by
Console.WriteLine(System.Runtime.InteropServices.RuntimeInformation.FrameworkDescription);
When compiling .Net Core RC2 project under VS 2015 I am receiving following error
GETSDKTOOLINGINFO : error : The .NET Core SDK is not installed or
cannot be found under the path C:\Program Files\dotnet\bin. These
components are required to build and run this project.
Files do exist under that directory.
Also when I input dotnet into command line I do see it's prining proper version number and stuff.(.NET Command Line Tools (1.0.0-beta-001598)
Any idea how to resolve the issue?
Remove all older versions of core
Unistall Microsoft .NET CLI for Windows from control panel if it exists. This helped me.
After you install RC2, Make sure your control panel shows ONLY these for .Net Core
Microsoft .Net Core 1.0.0 RC2 - VS 2015 Tooling Preview 1 (1.0.20513.14)
Microsoft .Net Core 1.0.0 RC2 - SDK Preview 1 (x64) to be version 1.0.0.2702
Hope this helps.
If you install VS 2015 and VS 2017 side by side you may end up with a situation where you have:
.NET Core 2015 x86
.NET Core 2017 x64
(Take a look in Control Panel > Programs and Features)
When you try to open a VS project/solution targeting .NET Core you get the error message described in this posting.
If you search on this error you may get taken to this page:
https://github.com/aspnet/Tooling/blob/master/known-issues-vs2015.md#missing-sdk
But the solutions described there don't work (such as editing your PATH to exclude the x64 version.)
HOWEVER .. from that page, download the x86 version of .NET x86
".NET Core 1.0.1 SDK 1.0.0-preview2-003131 download links"
CLOSE any open sessions of VS. Then uninstall .NET Core 2017 x64 and then install .NET Core x86 version you just downloaded.
Your Control Panel > Programs and Features should now look like this:
Control Panel - After
What this effectively does is that now all your .NET Core is x86 rather than a mix of x86 and x64.
Reboot not required.
Repair Microsoft .Net Core 1.0.0 RC2
In case the previous answer doesn't help you because the right version of dotnet core (SDK & Tools) is already the only one installed (I was in that case):
Repair both and that should fix your problem.
For anyone getting similar messages, here is the official Issue page in the CLI repo.
Of the mentioned workarounds, one is to remove the 'DotNet CLI' entries from the installed programs.
New update: 2021 Jan Update VS Code/ VS 2019/CLI: Get/Download LATEST CORE version
here
A) first check what you have --> run dotnet --info for runtime & dotnet --list-sdks for SDK, from the command line, then B) check which ones can be un/re-installed dotnet-core-uninstall list download MS tool from here IT WILL CLEAN uninstall correctly,
Now you can re/install .Net Core make sure you close your VS Code / VS Studio, and then do your un-install/install
(Windows Skip) for Mac only add your /usr/local/share/dotnet to PATH in your ~/.bash_profile
the install from here on Microsoft
To Fix Path for CLI commands, run these below it will add it to your path:
set DOTNET_ROOT=%USERPROFILE%\dotnet
set PATH=%USERPROFILE%\dotnet;%PATH%
set DOTNET_MULTILEVEL_LOOKUP=0
Check for dotnet --list-sdks.In my case there were none.
Installing the .NET Core sdk worked for me.
If above answers not works
Try this
If you installing 64 bit SDK's, Do uninstall x86 bit SDK's from the control penal
And Try in Visual Studio
It worked from me