
.NET Standard 2.1 - benaadams
https://blogs.msdn.microsoft.com/dotnet/2018/11/05/announcing-net-standard-2-1/
======
oaiey
I think they prepare already a while the shift to .NET Core as the primary
.NET platform (also on Windows).

\- .NET Core will soon run all three UI technologies of modern Windows UWP,
WinForms and WPF (.NET Core 3). \- The Windows Compatability Pack for .NET
Core shifted some popular .NET Framework libraries to .NET Core (some only on
Windows).

There are one thing, Microsoft is really bad with: Telling the world that
something is deprecated. There is a set of technologies in the .NET Framework
which have no future: AppDomains, WCF, Code Access Security, Workflow
Foundation, Cardspace, ... (just to name a few). They are all already dead for
some years, but no one tells. They are supported in the .NET Framework but no
progress happens. And .NET Core will never see them.

~~~
cptskippy
> Microsoft is really bad with: Telling the world that something is
> deprecated. There is a set of technologies in the .NET Framework which have
> no future: AppDomains, WCF, Code Access Security, Workflow Foundation,
> Cardspace, ... (just to name a few).

There's no reason to deprecate a mature product if there's need for it, it has
sufficient test coverage, and there's low/no maintenance. There is however a
risk involved with deprecating them that users will migrate to another
technology stack entirely.

WCF is one of those technologies that was deployed heavily in Enterprise and
is deeply ingrained in applications and systems going on a decade old. WFC has
better support for SOAP than anything I've seen in the open source world and
with a minor configuration tweak it can simultaneously support JSON from the
same endpoint.

Workflow Foundation is in a similar state to WCF, though I wouldn't shed a
tear if it vanished off the face of the planet.

~~~
skrowl
I agree. Don't deprecate just to clean house. Only deprecate when you have a
mature / table replacement.

------
stevecalifornia
Suggested naming standard:

\- .Net API Specification - (now known as .Net Standard)

\- .Net Windows - (now known as .Net Framework)

\- .Net Cross Platform - (now known as .Net Core)

~~~
legulere
There’s already universal windows platform, which is basically windows 10
only.

~~~
skrowl
Universal windows platform also runs on Xbox One and certain mixed-reality
headsets. It's not just for Windows 10.

------
kodablah
> Given many of the API additions in .NET Standard 2.1 require runtime changes
> in order to be meaningful, .NET Framework 4.8 will remain on .NET Standard
> 2.0 rather than implement .NET Standard 2.1. .NET Core 3.0 as well as
> upcoming versions of Xamarin, Mono, and Unity will be updated to implement
> .NET Standard 2.1.

At some point, is it reasonable to expect Xamarin, Mono, Unity, and .NET Core
to all really be backed by .NET Core? And if/when so, is there any difference
between .NET Standard and .NET Core since, after .NET Framework has been
essentially maintenance-mode'd, there will be only one .NET Standard
implementation? Similar question, besides just having multiple
implementations, what benefit is there to having both Mono and .NET Core
separate (at least for the .NET Standard impl part)?

~~~
oaiey
Mono and .NET Core will never merge. But it is not a black and white thingy.

.NET Core has a sub project named corefx (Base Class Library), which acts as a
master for most of the class library of Mono nowadays. However, the runtime
below (mono or coreclr for .NET) are different animals. Mono is highly
optimized on portable code (it runs in many more places than .NET Core) while
.NET Core is tuned for performance.

Unity is based on Mono but also has yet another different runtime (it
basically compiles the code first in C++ and then with C++ backends to the
target architecture). Expect here the same as for Mono. It is specialized and
will stay specialized.

~~~
kodablah
That makes sense with regards to the runtimes and non-spec'd libs. But I was
under the impression .NET Standard was essentially the class library spec and
if .NET Core is/becomes the only impl of that class library spec it would seem
strange to separate the spec from the impl when only one of each exists built
by the same blessed implementer. I can definitely understand different
compilers, AOT/JIT engines, GCs, etc. Even with minor .NET Standard impl
differences in Mono, if they are so minor that they only augment .NET Core, it
comes off as an optimization rather than a separate implementation. If the
class library impl differences remain major, I would wonder why as surely,
even when optimizing for portability vs performance, there is a lot of
potential reuse.

~~~
oaiey
Consider e.g. the cryptography support in the .NET Standard. On Linux it is
based on OpenSSL (AFAIR), on Windows based on the crypto library there, on
MacOS on another one, on Android another one and let us not speak of iOS. All
of them follow on the surface the same API spec. But behind the scenes all
.NET implementations have different strategies to deal with. And for good
reasons.

In this cases you need a standard but not a shared implementation.

~~~
kodablah
I don't think deferring by platform preference is enough of a reason to
separate the standard from the abstracting implementation. Most languages,
with or without a "standard" and multiple implementations, defer to the
platforms' preferred ways of, say, obtaining cryptographically random numbers.

------
SimonPStevens
Everytime I start to think Microsoft is heading in the right direction they go
and blow it all away again.

This week we've already had a new asp.net core which drops support for .net
standard and only supports .net core.

And now, a new version of .net standard that .net fx isn't going to support.

We are right back at the mess of portable class libraries with all their
different supported profiles.

It means app devs are constantly dealing with problems like "is this library I
want to use, supported by all the targets my app needs to run on", and library
devs have a mess of different frameworks and combinations to support, so
inevitability drop a few of them unless they are a big project with lots of
manpower.

~~~
oaiey
I need to highlight, that ASP.NET Core never run on .NET Standard. Some parts
always have been dual-compiled for netcoreapp2.0 and net46(?).

~~~
SimonPStevens
Ah, my mistake, I didn't know that. Kind of actually enforces my point of the
ecosystem being a mess though and the only realistic thing to do is compile
for multiple targets.

~~~
WorldMaker
I believe that ASP.NET Core should be able to move to .NET Standard 2.1
(Span<T> is the big reason they decided they needed to drop .NET Framework
support). They dropped .NET Framework, but there's still a case that they can
support .NET Standard here, for what that is worth.

------
Someone1234
Let me just check if I finally understand this:

\- .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?

~~~
taco_emoji
.NET Framework is not anywhere close to deprecated, AFAIK...

~~~
Someone1234
I guess it is a matter of perspective and your definition of the word
"deprecated". This is the definition I use (from Wikipedia):

> 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.

~~~
thrower123
There is still just a lot of stuff you can't do on Core alone. It's fine, I
guess, if you are doing fairly vanilla web server development, although the
last time I tried it was not the easiest to run .NET Core on Azure. Probably
the story is better there now than it was.

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.

~~~
WorldMaker
The .NET Standard 2.0 push moved a vast amount of code to being compatible on
.NET Core alone. The "desktop app packs" for .NET Core 3.0 to run WinForms and
WPF closes the gap a lot further.

(.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.

------
polskibus
It's a pity 2.1 will not be implemented by netfx 4.8. I wonder if there will
ever be E netfx with netstandard 2.1.

Sadly things are not looking good for standardization - on one hand we have
new netstandard without netfx and on the other aspnet.core without netstandard
([https://github.com/aspnet/AspNetCore/issues/3753](https://github.com/aspnet/AspNetCore/issues/3753)).

~~~
WorldMaker
The interesting thing to note is that the core runtime in netfx hasn't changed
in a long while (.NET Framework 3.x and .NET Framework 4.x are still
essentially CLR 2), and it sounds like after what Microsoft learned from the
CLR 1 -> CLR 2 (.NET 1.0 -> .NET 2.0) update they never want to do that again
if they can avoid it. CLR 1 to CLR 2 had a very good reason to do that
(generics); .NET Standard 2.1 has a lot of little reasons, but no good, big
reason to break the .NET Framework world with a runtime upgrade.

(Also, it looks like ASP.NET Core still should be considered .NET Standard 2.1
compatible, but yes the "upgrade" to .NET Standard 2.1 is fascinating because
it loses compatibility with netfx.)

~~~
oaiey
ASP.NET Core is not .NET Standard based. Most of its libraries are, but the
core runtime is bound to a platform like .NET Core (and earlier the .NET
Framework). It was never running on a pure .NET Standard interface.

~~~
WorldMaker
One of the biggest reasons for that seems to be Span<T>, so it seems possible
that ASP.NET Core can move toward .NET Standard 2.1, since it includes
Span<T>. Certainly it isn't guaranteed, but it seems plausible. (Not that it
would help much in the case that .NET Framework doesn't seem to be capable of
.NET Standard 2.1.)

------
c-smile
So they added Span<T> as a big thing ...

> (Span<T> is) at the heart of most performance-related improvements in .NET
> Core 2.1. Since it allows managing buffers in a more efficient way, it can
> help in reducing allocations and copying. We consider Span to be a very
> fundamental type as it requires runtime and compiler support in order to be
> fully leveraged.

Small struct that is declared as

    
    
        public readonly ref struct Span<T> 
        { 
          private readonly ref T _pointer; 
          private readonly int _length; 
          ... 
        }
    

which is exactly what I am using in Sciter
([https://sciter.com](https://sciter.com)) for 10+ years:

    
    
        template <typename T> 
          struct slice { 
            const T* start; 
            unsigned int length; 
            ... 
          } 
      

[https://github.com/c-smile/sciter-
sdk/blob/master/include/au...](https://github.com/c-smile/sciter-
sdk/blob/master/include/aux-slice.h#L48)

Such small thing definitely speed ups many areas and surprisingly quite a lot,
parsing in particular.

Nothing new under the Sun, eh?

~~~
nightski
Does your template work with memory managed by a GC and provide all the memory
safety guarantees that .NET does? If so, does it work seamlessly across the
stack & the heap for both managed memory and unmanaged memory at the same
time?

I get it, similar concepts - but let's not dismiss the value in this addition.

~~~
misnome
I didn’t read the poster as dismissing it (or claiming to have outright
invented the concept) - rather pointing out that good implementations
naturally keep re-arising.

~~~
c-smile
Yeah, this concept is quite old.

It reincarnated quite many times: in D language by Walter Bright where arrays
are just such slices. Or by Andrei Alexandrescu in its range<T> thing:
[http://www.informit.com/articles/article.aspx?p=1407357&seqN...](http://www.informit.com/articles/article.aspx?p=1407357&seqNum=10)

------
twblalock
I thought the Java framework nomenclature was bad, but .Net is way more
confusing.

~~~
int0x80
I was thinking about this... but I'm not so sure :)

JRE, JDK, Java EE, Java SE, Beans, Enterprise Beans, Managed Beans, JEE APIs
vs Implementations etc, containers, app containers, app servers.

'Enterprise' has to be the worst prefix/name ever for an API or technology.

It is a tough contest.

------
Nelkins
Anybody got any updates on the state of Mono/.NET Core convergence?

I actually don't care very much if they're actually the same code base, but
I'd like to be able to use the dotnet CLI for everything. Xamarin project
templates in the new SDK format are also on my wishlist.

~~~
BonesJustice
Are .NET Core and Mono converging? I would have thought that they'd remain
separate while both implementing .NET Standard, and becoming interchangeable
as .NET Standard implementations.

~~~
Nelkins
At least some convergence is happening: [https://www.mono-
project.com/news/2016/11/29/mono-code-shari...](https://www.mono-
project.com/news/2016/11/29/mono-code-sharing/)

And here's a more recent update: [https://www.mono-project.com/docs/about-
mono/releases/5.0.0/...](https://www.mono-project.com/docs/about-
mono/releases/5.0.0/#corefx--reference-source-adoption)

~~~
WorldMaker
Also, this article on .NET Standard 2.1 mentions that for new features to be
considered for future .NET Standard APIs they expect them to be MIT-compatibly
licensed in at least one .NET Standard implementation with option for the
other implementations to just use it outright, which indicates convergence as
a policy goal.

------
maxxxxx
I do mainly desktop dev but reading that Core is now the platform with rapid
improvements I wonder if it's possible to write WPF or UWP apps with .NET Core
or Standard.

Does anyone know?

~~~
michaelwda
This is coming in .NET Core 3. Slated for Q1 2019 AFAIK.
[https://blogs.msdn.microsoft.com/dotnet/2018/05/07/net-
core-...](https://blogs.msdn.microsoft.com/dotnet/2018/05/07/net-core-3-and-
support-for-windows-desktop-applications/)

~~~
qwerty456127
If WPF is coming in .NET Core, does this mean we are going to be able to run
WPF apps on Linux and Mac?

~~~
algorithmsRcool
Nope, it will be a windows only capability.

-Edit-

I should add that the purpose of them adding this capability isn't to set up a
new cross-platform UI suite. It is just to lure enterprise shops to .NET core
by supporting more of their .NET Framework workloads

~~~
solarkraft
I'm still wondering whether it would be smart for them to port WPF or UWP to
all platforms. They are already decoupling their services from Windows and a
UI library would be quite a flagship for them.

Then again they'd also lose the Windows vendor lock-in, which might still be
more valuable to them.

Then again they could sell their development toolchain and gain developer
sympathy.

~~~
algorithmsRcool
Well, I think it is an engineering problem. WPF is basically cemented to
DirectX which only exists on Windows.

------
hi41
I thought we already have .NET 4. I don't understand.

~~~
LandR
.Net framework is upto 4.7 .net standard is now 2.1 .net core is 2.1

~~~
hi41
Thank for clarifying all the "synonyms" associated with .NET. I did not know
there were three different things: framework, core and standard.

Are there others I am missing?

~~~
WorldMaker
Mono (5.0) and Xamarin (4.5) implement .NET Standard 2.0.

------
hnbroseph
i really wish they would say "the .net standard" rather than just ".net
standard". missing that prefixed article is confusing for someone not in the
ecosystem (or me at least).

even better would be "specification" rather than "standard", the later being a
word frequently used to indicate a particular version of some thing.

~~~
terrajobst
Totally fair. The original name was ".NET Standard Library" but we were too
lazy so we shortened it to just ".NET Standard", which then ended up becoming
the product name.

