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

Support .Net Framework (4.8?) for netstandard 2.1 #859

Closed
Daniel-Svensson opened this Issue Aug 28, 2018 · 20 comments

Comments

Projects
None yet
@Daniel-Svensson
Copy link

Daniel-Svensson commented Aug 28, 2018

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

This comment has been minimized.

Copy link
Member

terrajobst commented Sep 1, 2018

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.

@terrajobst terrajobst added this to the .NET Standard 2.1 milestone Oct 17, 2018

@terrajobst terrajobst self-assigned this Oct 31, 2018

@springy76

This comment has been minimized.

Copy link

springy76 commented Nov 2, 2018

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

This comment has been minimized.

Copy link

johnduhart commented Nov 5, 2018

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

This comment has been minimized.

Copy link
Member

terrajobst commented Nov 6, 2018

Yep. Closing.

@terrajobst terrajobst closed this Nov 6, 2018

@springy76

This comment has been minimized.

Copy link

springy76 commented Nov 6, 2018

RIP .NET Framework.

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

@slang25

This comment has been minimized.

Copy link

slang25 commented Nov 6, 2018

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

This comment has been minimized.

Copy link

trampster commented Nov 7, 2018

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

This comment has been minimized.

Copy link

slang25 commented Nov 7, 2018

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

This comment has been minimized.

Copy link

trampster commented Nov 7, 2018

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

This comment has been minimized.

Copy link

springy76 commented Nov 8, 2018

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

This comment has been minimized.

Copy link

slang25 commented Nov 8, 2018

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

This comment has been minimized.

Copy link

NetMage commented Nov 29, 2018

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

This comment has been minimized.

Copy link

gautelo commented Feb 6, 2019

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

This comment has been minimized.

Copy link
Member

danmosemsft commented Feb 9, 2019

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

This comment has been minimized.

Copy link

gautelo commented Feb 11, 2019

@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

This comment has been minimized.

Copy link
Member

danmosemsft commented Feb 12, 2019

@springy76

This comment has been minimized.

Copy link

springy76 commented Feb 12, 2019

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

@gautelo

This comment has been minimized.

Copy link

gautelo commented Feb 12, 2019

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

@lostmsu

This comment has been minimized.

Copy link

lostmsu commented Mar 4, 2019

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

This comment has been minimized.

Copy link

JensNordenbro commented Mar 8, 2019

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.