- .Net Framework: The Windows Specific (and nearly deprecated) branch
- .Net Core: The replacement for Framework and cross platform branch (but with Windows specific libraries)
- .Net Standard: A way to write something that runs on both .Net Framework and Core?
Note that executables cannot be compiled to .NET Standard, because they are self-bootstrapping so they must target one or the other (or both).
Standard = an API set. If you know OO in C# or Java this is effectively analogous to an interface.
It's the smallest common denominator of various implementations.
.NET Core = the new implementation
.NET Framework = the old implementation
.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.
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).
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.
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.
> In several fields, deprecation is the discouragement of use of some [..] feature
Microsoft are currently telling people for new projects only use .Net Framework if you have a specific requirement, otherwise use .Net Core. .Net Core is therefore the default choice.
That to me is discouragement which starts to put .Net Framework into the realm of depreciated. Is it deprecated yet? It is not, but it is definitely going in that general direction and you can see it on the distant horizon.
Microsoft also has the entire silent iceberg of enterprise development that is going to be slogging along with .Net framework applications for years and years. Billions of lines of code that work as is, and just are not going to be invested in to update them.
(.NET Core on Azure seems pretty easy to me. Even from early beta days of .NET Core, but there are certainly even more Azure tools for it today than then, including some really good .NET Core on Docker support from what I hear.)
Yes, enterprises will always be slogging along with ancient solutions so long as "if it isn't broke, don't fix it" aligns with the bottom line. Arguably that seems exactly why .NET Framework might not support .NET Standard 2.1+, because Microsoft doesn't want to accidentally break ancient enterprises if they can avoid it.
If you ask Microsoft, they'll currently tell you otherwise, but that's because that's a bad idea from a marketing perspective. You don't let your customers know you're going to end of life your product that they used for 15 years until you have absolutely no other choice.