[dragonwriter]

> that was the primary purpose before, but since .NET Framework will no longer be implementing new .NET Standard versions

.NET Framework 4.8 won't implement .NET Standard 2.1 doesn't mean .NET Framework won't implement new .NET Standard versions.

.NET Framework has been announced previously to be slower-movinh and lower-risk than Core, so it's not surprising that it will take longer for it to support new versions of .NET Standard. That the next Framework release won't incorporate the newest Standard doesn't mean Framework won't advance it's Standard support going forward.

[WorldMaker]

Microsoft here sounds extremely hesitant to ever do the ".NET Framework 5.0" release that would break the .NET Framework world necessary to push a new CLR Runtime out. .NET Framework 3.x and .NET 4.x have all still been using the CLR 2.0 (for the most part), and the risk at upgrading the CLR is far greater than the .NET Framework 1.0 to .NET Framework 2.0 era. (Certainly the "reward" of the new mostly performance-oriented features in .NET Standard 2.1 doesn't seem worth it at first glance, not compared to the CLR 2.0 upgrade for generics.)

[dragonwriter]

> Microsoft here sounds extremely hesitant to ever do the ".NET Framework 5.0" release that would break the .NET Framework world necessary to push a new CLR Runtime out.

Yeah, I think the question is "will Framework be the slow moving, but 'living' component you target for long-term, but perhaps not eternal, stability on Windows platforms or will it be a legacy component that Windows is burdened with only for backward compatibility with older apps".

I think Microsoft has sent signals out which point in each of those directions, but not yet converged clearly on one or the other.

[WorldMaker]

Yeah, I think Microsoft has changed its mind a couple times too many. With .NET Core's original announcement it sounded like .NET Framework was legacy and in mostly maintenance mode. With .NET Standard < 2.0 it seemed clear that .NET Core might move way too fast for .NET Framework to catch up, but maybe it was possible for it to catch up eventually, though there was some question there because there were some APIs it wasn't clear if .NET Framework would adopt at all for a bit there. I think .NET Standard 2.0 gave some at Microsoft a calm sense of ".NET Framework can keep up surely" as .NET Core paused to catch up with Mono/Xamarin's API footprints, but .NET Standard 2.1 here seems to make it clear that Microsoft realized again it can't keep up with .NET Framework. Definitely not in the short term, and probably not ever.

It would be great if they better articulated that "probably not ever", but I can't blame them for not doing that when we all know that a bunch of enterprise devs and HN/Reddit/Slashdot randoms would be out in force with pitchforks and torches if they did.

[gulbanana]

they have done it; it’s called “.NET Core”.

[WorldMaker]

I feel that way, too, but I understand some of the reasons people still want to see a ".NET Framework 5.x".

[zerocrates]

> This means that .NET Core will get new APIs and language features over time that .NET Framework cannot. At Build we showed a demo how the file APIs are faster on .NET Core. If we put those same changes into .NET Framework we could break existing applications, and we don’t want to do that.

The "slower" explanation doesn't really fit with that sentence to me... if Standard 2.1 already has things that Framework "cannot" have, then it seems like "stopped" is more accurate than "slower." I guess technically they only are saying that Core gets things Framework can't, not necessarily the standard, but I'm not sure that's much of a distinction in practice.

Of course it doesn't have to mean that Framework is just frozen but it would seem to make the Standard a bit of a dead letter (I'm not really familiar with how useful it is in terms of Xamarin/Mono/Unity).