The .NET Framework row is sligthly misleading

[0x53A]

The small footnote (1) is really inconspicious. I can understand that you want to sweep this under the rug, but it is important to know what is supported where.

The old table looked like this: https://cloud.githubusercontent.com/assets/4236651/26560789/86e0a85e-44b9-11e7-9e8f-427ad198a3cf.png

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: 9eb8b774-c6f0-8235-6964-15219baf2ea7
• Version Independent ID: 6819a4a7-7527-d8c7-e132-767f7344e00e
• Content: .NET Standard
• Content Source: docs/standard/net-standard.md
• Product: dotnet
• GitHub Login: @mairaw
• Microsoft Alias: mairaw

[svick]

Why do you think it's important to prominently document what the .Net Core SDK 1.x did? As far as I know, there is no reason to use that. Even if you want to target the .Net Core runtime 1.x, you can use the .Net Core SDK 2.x for that.

[0x53A]

The important difference is VS2015 vs VS2017. And VS2015 is still used in many companies (we are currently planning the move to 2017).

And even if you yourself are using VS2017, you should be aware that by using any NET Standard 2.0 component, you implicitly exclude anyone else using VS2015 (or even older).

[svick]

As far as I can tell, VS2015 only supports preview versions of .Net Core tooling 1.0. I don't think the documentation should focus on what old, preview versions do.

If you want to use .Net Core, you should really use VS2017 for that. (You can still keep using VS2015 for other solutions.)

[0x53A]

But it's not even about .NET Core, it's about full framework and old csproj format.

[dasMulli]

There is a .NET Standard 2.0 support package for VS 2015 but it has some problems that are about to be fixed soon (dotnet/sdk#1539). It requires manually installing the newest VS 2015 NuGet VSIX from https://www.nuget.org/downloads and following the download links it prints out when you're trying to reference .NET Standard NuGet packages.

Otherwise I agree that there is no reason to document tooling that is no longer recommended to be used.

Note: The second line was not only for preview tooling, but also for the 1.0 and 1.1 RTM SDKs in VS up until 2.0 tooling.

[0x53A]

It would be great if that information (link to the support package) could be added there. And even then, if the tooling is a manual installation (in contrast to an automatic update), then I'm not sure if I can expect everyone to have it installed.

So I still think the information that VS2015 supports NET Standard 1.4 (NET 4.6.1) and NET Standard 1.5 (NET 4.6.2) out-of-the box, and NET Standard 2.0 (NET 4.6.1) with the support package is really valuable.

Also, the support package hacks into the build process with MSBuild targets, and so is not available if you manually invoke csc. This is not something I do, but I know a company which does. So for them, afaik .NET Framework 4.7.1(?) is the first framework that supports NET Standard 2.0 out of the box.

Another reason is if you don't want to (or can't - think of plugins) depend on the deployed facades and need native support, then you also need .NET Framework 4.7.1(?) which includes these facades inbox.

---

Summarized, I think there should be two rows: native support, and supported through tooling and deployed facades.

[dasMulli]

4.7.1 still needs some facades. Only 4.7.2 has all the assemblies in-box that are needed to use csc only if you have dll references. But even for 4.7.2 there are some corner cases that are still not fixed without tooling support - dotnet/sdk#1738

Also, the support package hacks into the build process with MSBuild targets…

The same happens in VS 2017, only that the extension targets are preinstalled into VS.

cc @leecow about the link - I think I saw this more prominently on https://dot.net somewhere, but can't find it now (aside: the new download experience is a lot better though)

[mairaw]

@0x53A I wouldn't call that information a lie. It's what's currently supported in the most current versions of the SDK.

We decided to remove the 1.0 SDK information because it was causing confusion and I had several people requesting me that I clean that up on that doc. You can see the changed versions on the standard repo that we link to from the article: https://github.com/dotnet/standard/blob/master/docs/versions.md.

AFAIK you cannot develop .NET Standard libraries using csproj in VS2015, just consume them. I have an issue #2927 that I've been trying to get to it for months now. I'm hoping I can finally address it this current sprint. I just increased its priority yesterday during our triage meeting. VS2015 only supported the project.json format, which is not supported.

[0x53A]

Apologies, "lie" was a bit aggressive and unconstructive.

We decided to remove the 1.0 SDK information because it was causing confusion and I had several people requesting me that I clean that up on that doc.

I mean, the status-quo IS really confusing, because it is complex. But I am not sure if removing / hiding information reduced that complexity ...

AFAIK you cannot develop .NET Standard libraries using csproj in VS2015, just consume them.

Practically, the table serves two purposes:

• what can I produce?
• what can I consume?

Normally, I would expect both of these to be the same, if they aren't, then it might be good to explicitly call that out. In my case, the consuming part is more important, because for my own dependencies, I can just produce full-fx, but many third-parties switched to .NET Standard only.

But even for 4.7.2 there are some corner cases that are still not fixed without tooling support

:\ :sadpanda:

---

Some of the information in this thread I've seen already, strewn over multiple different github issues, other things are new to me. Would it make sense to add this either into the main documentation, or create a new page and link to it? NET Standard is praised as the cure to everything, but it is really hard to find detailed information about it.

And I'd like to repeat my previous ask:

Summarized, I think there should be two rows: native support, and supported through tooling and deployed facades.

As I read it, the native support row for NS2 would be vNext (4.7.3 ?) because even 4.7.2 has issues? That's really important information!

[leecow]

The .NET Core Tools for VS2015 are linked from https://github.com/dotnet/core/blob/master/release-notes/download-archive.md. @dasMulli , is this what you're referring to?

[mairaw]

I don't feel like we should add that information back. @terrajobst what do you think? I'm inclined to close this issue as by-design. We should encourage people to move to newer versions of the SDK.

[0x53A]

I'd like to reword my ask:

Please provide two rows, one for natively supported, one for supported through shims.

Scenario: I have a .NET Standard 2.0 Lib and NetFx4.x.y Exe. For which frameworks is my deployment 2 files, and for which frameworks is my deployment 100 files?

---

---

.NET Standard	1.0	1.1	1.2	1.3	1.4	1.5	1.6	2.0
.NET Core	1.0	1.0	1.0	1.0	1.0	1.0	1.0	2.0
.NET Framework	4.5	4.5	4.5.1	4.6	4.x.y	4.x.y	4.x.y	4.7.2
.NET Framework 1	4.5	4.5	4.5.1	4.6	4.6.1	4.6.1	4.6.1	4.6.1
Mono	4.6	4.6	4.6	4.6	4.6	4.6	4.6	5.4
Xamarin.iOS	10.0	10.0	10.0	10.0	10.0	10.0	10.0	10.14
Xamarin.Mac	3.0	3.0	3.0	3.0	3.0	3.0	3.0	3.8
Xamarin.Android	7.0	7.0	7.0	7.0	7.0	7.0	7.0	8.0
Universal Windows Platform	10.0	10.0	10.0	10.0	10.0	10.0.16299	10.0.16299	10.0.16299
Windows	8.0	8.0	8.1
Windows Phone	8.1	8.1	8.1
Windows Phone Silverlight	8.0

^{1 This row represents the .NET Standard versions supported through updated tooling (.NET SDK 2.0 and/or VS 2017) and additional DLLs (facades) which will need to be deployed with your app. This may not be suitable for some scenarios, examples include when you develop a library for consumption by lower-level tooling, or in a plugin environment where you do not control the host. For more information see this link}

• The columns represent .NET Standard versions. Each header cell is a link to a document that shows which APIs got added in that version of .NET Standard.
• The rows represent the different .NET implementations.
• The version number in each cell indicates the minimum version of the implementation you'll need in order to target that .NET Standard version.
• For an interactive table, see .NET Standard versions.

---

Whatever you decide to do, can you please at least mention the facades, and mention that there might be issues in plugin scenarios?

[terrajobst]

@dasMulli

But even for 4.7.2 there are some corner cases that are still not fixed without tooling support - dotnet/sdk#1738

What corner cases are you referring to? dotnet/sdk#1738 seems to only talk about 4.7.1. AFAIK 4.7.2 has no issues with consuming .NET Standard 2.0 binaries.

@0x53A

Please provide two rows, one for natively supported, one for supported through shims.

That makes it more complicated than it needs to be. My opinion is that we should probably jut change the cell from 4.6.1 to 4.7.2 once 4.7.2 is (widely) available. We can then add an asterisk that points people so some guidance on how to use .NET Standard 2.0 before that.

[Gonnagle]

In my opinion it would be really helpful to have the table to somehow indicate which framework versions have a "native" support and which with the "hacks". What @terrajobst suggests seems rather good approach (list the first version supporting it without additional tooling and footnote about the additional support since 4.6.1 via tooling).

[0x53A]

Well, nothing happened so far, so probably nothing will happen the next few months.