
.NET Standard 2.0 is final - benaadams
https://github.com/dotnet/announcements/issues/24
======
jongalloway2
For people confused about what .NET Standard is and how it relates to .NET
Core:

Here's an FAQ:
[https://github.com/dotnet/standard/blob/master/docs/faq.md](https://github.com/dotnet/standard/blob/master/docs/faq.md)
Here's a series of short videos from the product team explaining it:
[https://www.youtube.com/playlist?list=PLRAdsfhKI4OWx321A_pr-...](https://www.youtube.com/playlist?list=PLRAdsfhKI4OWx321A_pr-7HhRNk7wOLLY)

Short excerpt from the FAQ:

    
    
      .NET Standard is a specification that represents a set of APIs that all .NET platforms have to implement. This unifies the .NET platforms and prevents future fragmentation. Think of .NET Standard as POSIX for .NET.
    
      Having a standard solves the code sharing problem for .NET developers by bringing all the APIs that you expect and love across the environments that you need: desktop applications, mobile apps & games, and cloud services.
    

Conceptually, I think of it in terms of browsers and browser standards. The
relationship between .NET Standard and the various .NET platforms (.NET Core,
.NET Framework, Mono, Xamarin, UWP, etc.) is similar to HTML specifications
(e.g. [https://www.w3.org/TR/html5/](https://www.w3.org/TR/html5/)) and
individual browsers. Newer HTML features are available on newer browsers, and
some browser feature implementation is contextualized (e.g. some web features
don't make sense on a mobile phone browser). I know there are rabbit holes to
#wellactually on that, so if it doesn't work for you don't worry about it, but
as an analogy I've found it helpful.

Having a defined feature matrix makes it easier to see which APIs are
available for a given platform and version.

(Microsoft employee, .NET team member, Nazgûl)

~~~
dsp1234
Another analogy for .NET developers:

.NET Standard is like an interface

.NET Core is like a class that implements the interface

Desktop .NET framework is like a class that implements that interface

Mono is like a class that implements that interface

Like any other class/interface relationship, the class has to implement all
interface members, but may add class specific features

------
lwansbrough
Compatibility mode sounds like a godsend for those of us who have had to hold
back due to compatibility issues with third party code/libraries. It's a risk,
to be sure, but awesome that it's an option now.

Side note: very much looking forward to UWP targeting .NET standard. Not long
now before you'll be able to develop UWP apps for Ubuntu and Mac OS :)

~~~
jasallen
Microsoft's Xamarin Forms 3.0 (stable release later this year) allows you to
target Linux and Mac[1] and is very similar to UWP conceptually - UI written
once, run anywhere. It's just that Xamarin's "anywhere" is much larger :)

Disclosure: I work on Xamarin team at Microsoft

[1][https://forums.xamarin.com/discussion/85747/xamarin-forms-
fe...](https://forums.xamarin.com/discussion/85747/xamarin-forms-feature-
roadmap)

~~~
randomf1fan
Question for you - I have created a few (okay, two) UWP apps, but the limited
success of the store has made me look to using Xamarin. Only thing is,
Xamarin's XAML is sufficiently different from UWP's XAML that I got
disoriented and gave up.

If I want to target cross platform apps (including Linux and Mac), should I
wait for Xamarin Forms 3 or will UWP eventually expand to cover Mac & Linux?

I'm only a hobby programmer so I don't want to waste hours learning something
that will be a dead end.

Any insight you might have would be very useful! thanks

~~~
pjmlp
Microsoft is working out a XAML standard to cover that case.

If you check BUILD 2017 sessions, there were a couple of talks about it.

~~~
DaiPlusPlus
Will the new XAML version (the first one in 10+ years!) finally solve the
problems of excessively verbose syntax, excessive XML namespace imports,
excessive binding syntax options, and excessive-needing-to-search-
stackoverflow-to-do-the-simple-things? :)

Any news on allowing JSON or another syntax as an alternative to XML-based
XAML?

~~~
snuxoll
JSON is no where near expressive enough to replace XAML, it would look a lot
worse than what we have right now.

The XML-like syntax of XAML isn't the problem, it separates object properties
from child content well due to it's nature - the bigger issue is how difficult
binding syntax is to grok by anyone who hasn't been working with it for quite
some time.

~~~
DaiPlusPlus
> it separates object properties from child content well due to it's nature

This is only the case for trivial properties - there is also the expanded form
of properties and that's where it muddies XAML very quickly.

For example, in a WPF project of mine I have a DataGrid with a Templated
column parenting an ItemsControl with HyperLink children (it displays a list
of Phone numbers for each Customer row).

This is my current XAML - I understand this is the minimum I need to achieve
that effect: [https://pastebin.com/cRjT2PG5](https://pastebin.com/cRjT2PG5)

It could be simplified drastically in two ways, for example:

* Eliminate `<ItemsPanelTemplate>` and `<DataTemplate>` elements, they're implicit in 90% of cases and yet add another element and indent level without conveying significant information. They could be expressed as attributes of the `<ItemsControl.ItemsPanel>` and `<ItemsContorl.ItemTemplate>` property elements.

* Allow C# expressions and the composition of child-binding to be used in property bindings, not just `String.Format` strings. In my example I have to populate `<Hyperlink.Tooltip>` with a full `<TextBlock>` and `<MultiBinding>` element - why can't I just do `<HyperLink ToolTip="{Binding Kind} {Binding Number}">`? That alone would 10 lines of my 42 line example.

Another issue with XAML is that the creators of XAML failed to learn from
HTML+CSS: while it succeeds at separating programming code from view-level
concerns, it fails at separating presentation from content - it's like we're
back in HTML3/4 days when <table> and <font> were all around and it was nearly
impossible to tweak and standardise a UI. XAML does have <Style> and <Setter>
elements but they're more used for setting Template properties - the end
result is a horrid mess.

~~~
snuxoll
> * Eliminate `<ItemsPanelTemplate>` and `<DataTemplate>` elements, they're
> implicit in 90% of cases and yet add another element and indent level
> without conveying significant information. They could be expressed as
> attributes of the `<ItemsControl.ItemsPanel>` and
> `<ItemsContorl.ItemTemplate>` property elements.

XAML ultimately compiles to an object tree, if you're putting more than a
reference, string, int, etc. into a property you need to construct it as a
child element - if you want you are free to define the DataTemplate elsewhere
in your XAML or in a resource dictionary and use the binding syntax.

> * Allow C# expressions and the composition of child-binding to be used in
> property bindings, not just `String.Format` strings. In my example I have to
> populate `<Hyperlink.Tooltip>` with a full `<TextBlock>` and
> `<MultiBinding>` element - why can't I just do `<HyperLink ToolTip="{Binding
> Kind} {Binding Number}">`? That alone would 10 lines of my 42 line example.

Use a converter? I know they're cumbersome to write, but that's what they
exist for.

> Another issue with XAML is that the creators of XAML failed to learn from
> HTML+CSS: while it succeeds at separating programming code from view-level
> concerns, it fails at separating presentation from content - it's like we're
> back in HTML3/4 days when <table> and <font> were all around and it was
> nearly impossible to tweak and standardise a UI. XAML does have <Style> and
> <Setter> elements but they're more used for setting Template properties -
> the end result is a horrid mess.

Again, resource dictionaries, bind reusable styles to your elements. Syntax
again sucks, `<TextBlock Style="{StaticResource AwesomeTextBlock}"/>`, and
there IS the nagging issue that the styles are decided by the UI - but it's
not too much worse than CSS classes.

Don't take any of this to mean your concerns aren't valid, but it's really not
_AS_ bad as you make it out to be. There's always room for improvement though!

------
curiousDog
Such a confusing name. I thought this was the .NET Spec publication. Still
better than .NET 365 Premium Plus I guess :-)

~~~
iokevins
".NET Standard is a specification that represents a set of APIs that all .NET
platforms have to implement. This unifies the .NET platforms and prevents
future fragmentation. Think of .NET Standard as POSIX for .NET."

[https://github.com/dotnet/standard/blob/master/docs/faq.md](https://github.com/dotnet/standard/blob/master/docs/faq.md)

------
smitherfield
So just so I'm clear,

.NET ECMA Spec ⊆ .NET Standard ⊆ (.NET Core ∩ Mono ∩ Xamarin ∩ Unity) ⊆ .NET
Core ⊆ .NET Framework

Correct?

~~~
jasallen
ECMA spec is for the CLI, essentially the specification for runtime like type
system and GC and all the other things that make an environment work at all

Net Standard is a specification of APIs. So in order to be compliant to the
standard you must have a class named X with parameters string Y, int Z.

"Net Framework" is the name for the Windows "full .net framework" \-- this
doesn't have a descriptive name since it was before all the rest, but
basically its an SDK that is a superset of the Net Standard (and therefore is
.Net Standard compliant / interoperable)

Mono is a open source implementation of "Net Framework" that runs on multiple
platforms (linux, etc). It attempts to treat full .NET Framework's surface
area as a spec but re-implement it cross platform. It is _also_ a open source
CLI implementation. So in common speech "mono" like ".net" can refer to either
the "basic sdk" _or_ the runtime environment.

Xamarin is forks of mono for iOS, Android and Mac platforms plus libraries
that include full support for interacting with those platforms Native SDKs

Unity is a fork of Mono plus gaming tooling and runtime tools. Microsoft does
not maintain this, it's a separate company.

~~~
smitherfield
To be more clear, I wasn’t actually confused, just commenting on how confus
_ing_ the various meanings of “.NET” are getting, and maybe helping clear up
some of the confusion for people who think visually and remember their
discrete math (set theory).

Of course it’s still helpful to plenty of people reading this thread to define
all those terms. :)

------
LyalinDotCom
Awesome milestone, so happy to see progress with .NET Standard as it makes
developers lives a lot more predictable.

On that note... a shameless plug :), don't miss .NET Conf 2017 our 3-day
digital event that will talk all about .NET standard 2.0 and much more in
Sept.

Sept 19th - 21st, watch anywhere details at:
[http://www.dotnetconf.net/](http://www.dotnetconf.net/)

------
ko27
Does anybody have any idea what is the total number of APIs available in .NET
Framework? I am interested how big of a subset .NET Standard is.

~~~
terrajobst
The .NET Framework has approximately 250k APIs. The majority are from the
application models stacks (WinForms, WPF, and ASP.NET).

.NET Standard has about 32k APIs that set is pretty close to all the APIs that
are part of .NET Framework that aren't specific to any application models.
However, we still have a few things we need to bring to .NET Standard.

~~~
flukus
Are we calling public classes API's now?

~~~
terrajobst
APIs are a long standing name for the set of all .NET constructs (classes,
structs, delegates, interfaces, methods, properties, events, fields).

In total, the .NET Framework has about 15k types.

------
UK-AL
Heh, .Net Contracts is in there. I thought that was basically unmaintained.

------
Manager
I can already see some APIs that were missing in 1.6 that I need. Extremely
exciting and will definitely making transitioning to .NET core so much easier.

------
maxxxxx
I don't really get what the purpose of this spec is. I would much prefer if
they spent the time on improving the .NET Core story. In typical MS manner
.NET seems to get more confusing all the time.

~~~
terrajobst
I can totally share the sentiment around complexity. We're working hard
towards reducing it though and .NET Standard is one piece of the puzzle. Let
me try to explain:

If you're a typical .NET customer, then you're used to the .NET Framework,
which also means you're probably only used to doing development on Windows.
That was no longer a viable strategy for .NET, so we're now pursing a cross-
platform strategy. A good chunk of the complexity you see today is a result of
the changed dynamics of software engineering: the PC is no longer the only
relevant form factor, server applications have to be rethought as scalable
cloud services, and the UI paradigm is no longer a sequence of dialogs but has
to be tailored to multiple clients, and on top of that you now also have to
deal with multiple different operating systems.

.NET has a long standing history of embracing the underlying platform (hello
COM, hello P/Invokes) while also providing a ton of conveniences on top that
make it approachable (hello WinForms). We can't really shield you from all the
complexities that result from the changed dynamics. But what we can do is
making it more consistent and productive.

Over the last years, various different .NET stacks were created, several of
them outside of the Microsoft bubble (Mono, Xamarin, Unity). So in order to
build modern experiences, you often have to use various different stacks to
get the job done. We understand that this isn't free of challenges, which is
why we try very hard to reconcile the differences. For instance, we acquired
Xamarin to fully embrace the mobile support they offer and make it a fully
integrated part of the .NET development platform. We changed the license on
Mono to enable Unity to use the latest version and pick up innovation
instantaneously. And we've created the

.NET Standard is a way to achieve API consistency between different .NET
stacks. This makes it much easier for application and library authors to share
code between different .NET implementations.

Our goal is to empower .NET developers to build any kind of app, for any kind
of operating system. That's the world we live in now and we're fully committed
to make this experience as productive as possible.

~~~
maxxxxx
I am not sure if you are going about this the right way. Instead of doing .NET
standard, .NET Core and .NET full framework with overlapping functionality, I
think it would better to have .NET Core as the underlining cross-platform
standard. Then add WPF, WCF and whatever as separate packages that may be
cross-platform or not.

The whole thing reminds me a little of the UI situation. Start with Winforms,
don't improve it but start WPF (and keep Winforms), then start Silverlight,
then start UWP. All in parallel instead of building on top of each other.

MS doesn't need more more frameworks, but less.

~~~
snuxoll
.Net Standard isn't an implementation, it's a specification. Code that targets
.Net Standard is guaranteed to run on any compatible runtime that supports it.

.Net Core has API's that aren't applicable to the Windows full-fat Framework,
Mono or Xamarin - you don't need or want them there.

~~~
Rusky
All of these API surfaces are pretty large- what is a good way to get a feel
for what they do/don't offer? In particular, what are you referring to in .NET
Core that you wouldn't want in Framework?

~~~
snuxoll
.Net Core supports P/Invoke on Linux and macOS, you aren't going to be using a
library that provides bindings for libsystemd.so or whatever on Windows - this
is probably one of the most prominent examples. I know there's a handful of
others, but I'm having a hard time finding a good article or any relevant
documentation on it.

