.NET Core November Update - 2.1.14, 2.2.8, and 3.0.1 #3848
Comments
|
Sorry, that is a mistake, it is being fixed now. the change will be live in a few mins. Since, this (non-sec) Core release is out of sync with VS releases, it will go out with the next set of VS releases in future. |
|
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? |
Wondering this as well. The same goes for 2.1.14 which contains SDK 2.1.607 whereas 2.1.13 contains SDK 2.1.802. |
|
This now supports F# 4.6 instead of F# 4.7 like the 3.0.100 SDK? May I ask why this is rolled back a minor version? |
|
@AngelosP, F# version issue should be fixed now, thanks for reporting. |
|
@vivmishra what about all the messed up 2,2 SDK versions |
|
@jamshedd what about all the messed up 2,2 SDK versions |
This is expected - .NET Core SDK versions are supported based on the Visual Studio lifecycle. The Visual Studio version (16.2) that includes the 2.1.802 SDK went out of support when VS 16.3 shipped, so we did not ship the corresponding Core SDK. @vivmishra, can you please confirm the version numbers I quoted are right? |
|
Yes, the versions are right. 2.1.802/2.2.402 shipped with VS 16.2 that went out of support when VS 16.3 went live. We understand that is confusing for people - we are working on a response for this. |
@jamshedd & @vivmishra so based on that which is what is the correct sdk to install for VS 2019 v16.3 or v16.4 ? as you dont really answer that question. |
|
@madhon , there is no update for v16.3 as this out of band (non-sec) .NET Core release did not align with any planned v16.3 release. v16.3 is now currently out of support as v16.4 went live on 12/3. Of course, you can still install any of the 2.X or 3.0 package (as per your need) from this release on v16.3, but, you should ideally upgrade to v16.4 as that is the officially supported version. v16.4 already includes what we have to offer from this release (2.1.14, 2.2.8, 3.0.1) plus 3.1 SDK. |
|
@vivmishra,
And which one of these I should use with latest version of VS 2019 Build Tools at my build server? Could you please advise? |
|
@zhaparoff, .NET Core SDK 2.2.X is not supported on v16.4. v16.4 already ships with .NET Core SDK 3.1 that is capable of building 2.X apps.
|
This creates a problem for linux package managers which now expect that the latest available 2.2 SDK version is 2.2.402 (runtime 2.2.7), when it is actually 2.2.207 (runtime 2.2.8). The only way to get the recent patches to 2.2.8 with the sdk is to either install manually, or force a package "downgrade" from .402 to .207. It's super weird and confusing and IMO should be addressed. |
|
What @hempels cited above is true of Docker, too. Pulling latest for the SDK 2.2-alpine3.9 tag "upgraded" it from 2.2.402 to 2.2.207. I figured the tags on Dockerhub would give options or clear things up, but for some reason no 2.2 tags are listed on https://hub.docker.com/_/microsoft-dotnet-core-sdk... but I'm still able to pull it from MCR. (Does someone need to fix that, btw?) From the above, I understand MS's perspective: there were multiple release branches (e.g. 2.2.2xx and 2.2.4xx) meant for compatibility w/ different VS versions (16.0 and 16.2, respectively). Each got bumped with each new runtime release: v2.2.6 had 2.2.205 and 2.2.401, v2.2.7 had 2.2.206 and 2.2.402. But when a VS release drops out of support, its SDK branch halts; so we never saw a 2.2.403, making 2.2.207 the single newest SDK version with runtime 2.2.8. For regular users, though - especially those who don't even use VS (and the download page takes pains to say you can use the SDK with CLI or ANY editor) - this is highly confusing and hinges on SKU and support information most users are oblivious about. And other questions arise: if 16.2 isn't supported anymore in favor of 16.4, why is the older 16.0 still getting a 2.2.207 release... because it's the VS 2019 base version? Either way, it's got to be confusing on sight to most users. It would be great if this kind of thing would be acknowledged on the downloads page, the release notes, and/or here, along with clear advice. |
|
Exactly right. This is an extremely important point, all MS employees should be required to cite this mantra each morning before work three times: "dotnet is not Visual Studio. Visual Studio is not dotnet". Visual Studio is of course free to take dependencies on dotnet SDK versions, but the opposite is not true. There can be no expectation that an SDK user (or package manager, or Docker maintainer, etc) knows anything about Visual Studio or its versions, and certainly we should not be seeing EOL for SDK versions on the basis that a VS version that depended on it is no longer supported. That would be like saying Windows Server 2012 will stop receiving updates because IE 10 is no longer supported. |
|
Yep, it's the codependency between the two that's most surprising. I use the SDK across multiple platforms in VS Mac, VS Code, Rider, and CLI as well as VS proper, and none of the others seem to be lacking vital features despite the SDK knowing nothing about them. I'm confused as to the benefit of the VS dependency, and I'd be interested to know the rationale. |
|
Closing older announcement issues. |
and others
Included fixes address issues detailed in the release notes.
.NET Core
.NET Core 2.1.14 and .NET Core SDK 2.1.510
Release Notes
Download 2.1
.NET Core 2.2.8 and .NET Core SDK 2.2.110
Release Notes
Download 2.2
.NET Core 3.0.1 and .NET Core SDK 3.0.101
Release Notes
Download 3.0
Please report any issues you find with these releases, either responding to this issue, creating a new issue here or creating a new issue in one of the following repos:
.NET Support Policies
Microsoft support policies are defined in the following documents:
The text was updated successfully, but these errors were encountered: