Support .Net Framework (4.8?) for netstandard 2.1

[Daniel-Svensson]

There is currently no mention here about which platforms will be supported apart from .net core. So adding this issue to track the framework support.

Netstandard is a good way to target all the major .net platforms. As such it should continue to support the .Net Framework which is still very much used.

[terrajobst]

The .NET Framework 4.8 feature set is still being decided on, which is why we haven't shared any plans yet. As soon as that's decided, I'll update the planning doc.

[springy76]

I just wanted to ask the same question.

Now that 3 days ago it has been announced that asp.net.core will not support .netframework anymore: https://blogs.msdn.microsoft.com/webdev/2018/10/29/a-first-look-at-changes-coming-in-asp-net-core-3-0/

This sounds like netstandard2.1 for netframework will not happen at all.

But this rises another question: If everyone has to reference netcore soon, is there any sense for netstandard at all?

[johnduhart]

Latest blog post makes this clear, netfx 4.8 will not support .NET Standard 2.1.

https://blogs.msdn.microsoft.com/dotnet/2018/11/05/announcing-net-standard-2-1/

[terrajobst]

Yep. Closing.

[springy76]

RIP .NET Framework.

It will not take long till the first NuGet dependency will become netstandard2.1+ only, and then BOOM!

[slang25]

People will be mutlitargeting netstandard2.0 for a long time. It's not reasonable to expect all frameworks to be locked together in features.

[trampster]

netstandard was proposed as a solution to nightmare that was PCL. It was to be a common set of features that all frameworks would support. This just killed that.

Either we consider .NET Framework to be dead and therefore not included in all frameworks. or netstandard has failed in it's goals.

[slang25]

No, it was never a goal to have all runtimes support the same features. It was to simplify how we refer to API sets so that we could have broader terms for them. All target frameworks support .NET Standard as a concept, and implement some level/version of netstandard, but they don't all support the latest version of netstandard, that is a deliberate fundamental part of how it works.

[trampster]

That's a shame because with .NET Standard 2.0 we had the ability to target everything with the one library. However with new Features like span restricted to 2.1, library devs are back to having to make compromises to ether multi target and emit features from some frameworks, or not use new features at all.

[springy76]

People will be mutlitargeting netstandard2.0 for a long time

Time will show but I don't believe. Nobody voluntarily floods his code with #if pragmas when not being forced to. Similarily when I write code using C#7.3 features I don't spend time in doubling my code by trying to find out how to write the same using C#7.0.

[slang25]

That comparison doesn't work for a number of reasons.

But I do hear what you are saying, if someone creates a new library, they might select netstandard2.1 and they will be excluding the full framework from consuming it. I'm hoping that the defaults and the guidance makes it clear the consequences when you are doing "File -> New...". I don't see libraries with existing users just dropping netstandard2.0, there will be a period of conditional compilation, and that would likely be kept for years. We will see.

[NetMage]

And now a lot of C# 8 requires .Net Standard 2.0 / .Net Core 3.0 and won't be working with .Net 4.8.

[gautelo]

Does that mean that there will be a .Net Framework 4.8.x or 4.9.x that will support netstandard 2.1? I mean, if there is no plan to implement the standard in anything but dotnet core, then why not simply work on dotnet core?

Don't get me wrong, I think that would be a mistake, but only under my assumption that the full framework would continue to support new netstandard versions.

If there are no such plans, I'm basically receiving a message saying I should not write libraries targetting netstandard 2.1. Is that what you want? I know I'd like to see my code thrive and be used.

If you're trying to send a different message, you need to clarify!

Or is the reasoning here that I should only target 2.1 alongside other targets and code conditionally for each one? If so, that's an abysmal message. I do not want to do that. It sounds like a mess and a ton of pain... I suppose such branching is fine for large public facing libraries. But for internal libraries, I should not have to do that.

I realise that there are several teams trying to coordinate these things, and that getting everyone on the same page can be hard. But this needs to be sorted out...

[danmosemsft]

no plan to implement the standard in anything but dotnet core, then why not simply work on dotnet core?

We expect Mono/Xamarin to support it, and most likely Unity to in due course.

[gautelo]

@danmosemsft I see. My mistake. I've been thinking in terms of only two of the platforms; fullframework & dotnet core.

At least then it makes sense, even if I think it's a pity that the fullframework won't get support. I suppose that simply means we should all hasten to move away from fullframework asap, or be left in the dust. ;)

[danmosemsft]

@gautelo :)

[springy76]

If you look at my comment from Nov 2th, we already have entered a loop here ;)

[gautelo]

@springy76 Yeah, I read the whole thing. I just wanted to voice my support and add some pressure.

[lostmsu]

I am specifically concerned about System.Range and System.Index, that are part of C# 8.
Unless they are supported, my scientific library will have to drop them as a feature to be usable in enterprise.

[JensNordenbro]

I worry this will hamper libraries that want to use the high performance constructs of .netstandard2.1 and hence be counter productive since .NET Core applications also will run without the non-Span, non-SIMD, non-Whatever features inside the libraries when .NET Standard 2.0 is the common ground.