
Introducing .NET Standard - runesoerensen
https://blogs.msdn.microsoft.com/dotnet/2016/09/26/introducing-net-standard/
======
Analemma_
I understand that Microsoft has to clean up a lot of legacy baggage around
this ecosystem, and it does look like the way forward is much clearer and
nicer, but man, was there any way this could've been done without _another_
".NET <foo>"? I'm still figuring out .NET Core/4.5/Framework and all the ASP
naming zaniness... and I'm a .NET developer! I do trust Microsoft that this is
really, truly the last time this will have to be done, but god it's a
headache.

~~~
ep103
I agree 100%.

So anyone care to take a stab at it? How does this differ from .Net Core?

~~~
terrajobst
.NET Core is a specific .NET platform while .NET Standard is a specification
that many .NET platforms, including .NET Core, implement.

In other words, .NET Standard is POSIX for .NET.

~~~
Someone
Small correction: .NET Core _will_ implement it. It has to grow quite a bit to
get there.

At least, that's my reading, but they manage to be fairly confusing by mixing
present tense and future tense with two different names:

 _" \- .NET Standard is a set of APIs that all .NET platforms have to
implement. This unifies the .NET platforms and prevents future fragmentation.

\- .NET Standard 2.0 will be implemented by .NET Framework, .NET Core, and
Xamarin. For .NET Core, this will add many of the existing APIs that have been
requested.

\- .NET Standard 2.0 includes a compatibility shim for .NET Framework
binaries, significantly increasing the set of libraries that you can reference
from your .NET Standard libraries.

\- .NET Standard will replace Portable Class Libraries (PCLs) as the tooling
story for building multi-platform .NET libraries."_

So, do we have _".NET Standard"_ now and _".NET Standard 2.0"_ in the future?
If so, why don't they say ".NET Standard 2.0 _will include_ a compatibility
shim for .NET Framework binaries"?

On the other hand
[https://github.com/dotnet/standard/blob/master/netstandard/p...](https://github.com/dotnet/standard/blob/master/netstandard/pkg/NETStandard.pkgproj)
seems to indicate the two are synonyms, and version 2.0 is the first version
of this framework.

~~~
dragonwriter
> So, do we have ".NET Standard" now and ".NET Standard 2.0" in the future?

There are three key versions (and several others; they have 1.0 through 1.6
and 2.0) of .NET Standard referenced; the key versions are 1.5 (supported by
.NET Framework 4.6.2 and later and .NET Core 1.0 and later), 1.6 (supported by
.NET Framework vNext and later and .NET Core 1.0 and later), and 2.0
(supported by .NET Framework 4.6.1 and later and .NET Core vNext and later).

~~~
Someone
So, in a blog post titled "Introducing .NET Standard", it turns out .NET
Standard already has 8 different versions?

Also, rereading the article, I notice _" When we shipped .NET Core 1.0, we
also introduced .NET Standard."_

This text really could do with a good editor.

~~~
dragonwriter
> it turns out .NET Standard already has 8 different versions?

I think the versions prior to v1.6 were retrospectively defined based on the
common capabilities of pre-existing platforms; v1.6 was what .NET Core 1.0
supported and .NET Framework vNext will support (2.0 is what .NET Framework
4.6.1 supports and what .NET Core vNext -- and vNext of MS's other platforms
-- will support, and beyond 2.0 there will be more synchronous development
across different platforms.)

~~~
terrajobst
That's exactly what happened, yes.

------
arenaninja
In the last 10 years I wouldn't have bet on C# to be the language to be the
most excited about, and yet here we are. Kudos for dealing with fragmentation

~~~
2bitencryption
I started using Xamarin to develop an Android app, expecting the Xamarin
platform to be some gross in-between which only exists to squeeze just a few
more developers onto C#.

But, no joke, it's a BETTER experience than Android Studio. I had a much
better time using Xamarin Studio (on OS X) and Visual Studio with Xamarin (on
Windows) than I ever did with Android Studio. And not just because of the
tools: C# provides so many great features that make Android development
awesome on it. And the API is essentially the same as the true Android Java
API; I found myself googling "start an activity on Android" rather than
"Xamarin start an activity on Android" because it's all done the same way.

I normally don't obsess about my code looking clean and beautiful, but when I
wrote my simple app in C# it shorter and easier to read than when I did it in
the Android Studio.

~~~
pjmlp
I still don't understand how Microsoft was able to provide a better debugging
and tooling experience for Android, than Google itself for their own OS,
although Android Studio 2.2 finally seems to be usable.

~~~
Delmania
> I still don't understand how Microsoft was able to provide a better
> debugging and tooling experience for Android, than Google itself for their
> own OS, although Android Studio 2.2 finally seems to be usable.

Visual Studio was first released in 1997, the company has 20 years experience
in designing and building tooling. I believe they also have a very firm
dogfooding policy, and some very intelligent people work there.

Google changed the search engine landscape and created the only competitor to
the iPhone, but building tools and tooling is definitely not a key strength.

~~~
pjmlp
Surely a few of those PhDs able to draw inverted tree algorithms on the
whiteboard should be capable of producing a proper IDE that doesn't hang the
computer all the time, an OS simulator and get their mind around how to have
an actual working build system for NDK users.

------
bmurphy1976
I can't really make heads or tails of this, it's still fairly complicated and
I'm just not invested enough in it to read everything with a fine toothed
comb.

What I want to know is, will the sync (not async/await) methods be available
on Linux on .NET Core? We've been struggling with that, the move to
async/await is a major rewrite of our legacy application codebase and for what
we do Mono has been a constant thorn in our side.

In an ideal world the old sync APIs would just work and we'd be able to move
forward with .NET Core as it stabilizes and get off Mono without a major
rewrite.

~~~
mellinoe
> What I want to know is, will the sync (not async/await) methods be available
> on Linux on .NET Core?

Yes, they most likely will be. If you search through the reference assembly
interfaces listed here, you should be able to tell whether the functionality
you want will be available.

[https://github.com/dotnet/standard/tree/master/netstandard/r...](https://github.com/dotnet/standard/tree/master/netstandard/ref)

For things like legacy synchronous or Begin/End async methods, we are more or
less adding them wholesale to the standard. If something like that is still
missing, then it's most likely an accidental omission rather than a conscious
removal.

(I work on .NET at Microsoft).

~~~
bmurphy1976
I don't see anything for WebRequest in the referenced repository, but thanks
for responding. I'm more hopeful than I've been since we found out .NET Core
was async/await only.

Migrating to async/await is very close to a complete rewrite for our codebase.
We're not interested in it because it's such a big undertaking, and if we're
forced to we might as well consider options other than .NET. My preference
would of course be to leave things that work as-is and get on with the more
important aspects of running our business.

~~~
taspeotis
I have been grafting asynchronous support into my codebase by a) writing new
code with it and b) using AsyncContext [1] to run asynchronous stuff
synchronously.

The performance:lines of code ratio you can get with async is quite high.
Using ADO.NET you can run mutually exclusive queries in parallel for up-to a
2x speedup (depending on what the queries need to do):

    
    
        using (var connection1 = ...)
        using (var connection2 = ...)
        {
            var getSomething1Task = GetSomething1Async(connection1, ..., cancellationToken);
            var getSomething2Task = GetSomething2Async(connection2, ..., cancellationToken);
    
            await Task.WhenAll(getSomething1Task, getSomething2Task);
    
            // now aggregate results from 1 and 2
        }
    

And it's more or less the same lines of code you'd need for the synchronous
version.

[1]
[http://stackoverflow.com/a/9343733/242520](http://stackoverflow.com/a/9343733/242520)

~~~
tychuz
Yes, multithreading is stupidly easy nowadays. I also use Parallel.ForEach and
sometimes .AsParallel() - changing "header" of foreach/for cycle is easy peasy
and performance gains are instant. :)

------
mythz
As a library author having to target multiple platforms .NET Standard +
project.json is much less painful to support than PCL's - looking forward to
when we can drop PCL's and just ship .NET Standard builds.

~~~
mmargerum
Sounds to me like project.json going bye bye

"After looking at our choices, it was apparent that it would be easier to move
.NET Core projects to .csproj/MSBuild so all .NET projects use the same
tooling and build system."

~~~
mythz
yeah they're getting rid of project.json but they're merging the multi
targetting benefits of project.json back into .csproj

------
euroclydon
I lead a .NET development team, and I have no plans start using Core any time
soon. That's based on my experience testing it out -- just too different, too
based on a myriad of nuget packages (which is too much like NPM for me).

This confirms my decision. I'm sure it will be nice once it's all sorted out.
The money quote for me is below:

 _Since our goal was to represent any .NET platform we had to break it up into
smaller NuGet packages. This works reasonably well if all these components can
be deployed with the application because you can update them independently.
However, when you target an abstract specification, such as PCLs or the .NET
Standard, this story doesn’t work so well because there is a very specific
combination of versions that will allow you to run on the right set of
platforms. In order to avoid that issue, we’ve defined .NET Standard as a
single NuGet package._

~~~
arenaninja
Here's the other side of the coin, as someone who's worked primarily with npm
(JS), composer (PHP), had a taste of cargo (rust) and of course yum, apt-get,
etc.: packages are awesome. npm is weird and hellish because people write
single-function packages, but that isn't the case in other ecosystems. NuGet
provides an easy and familiar way for me to get into it, as opposed to having
to absorb the entire ecosystem at once.

I agree though, that the challenge is different in a compiled language (from
JS/PHP), and when dependencies get specific you might be out of luck (when
.NET Core was announced I had a hard time following Microsoft's own tutorial
because minor revision was different between two key packages)

~~~
douche
Nuget does get a little fun when you are dealing with a solution with multiple
library projects that feed into a final executable. So far, I've either had to
upgrade all versions of a Nuget package across projects, or spend a lot of
time messing around with app/web.config assembly redirects.

At least the granularity of Nuget packages is not at npm-level fineness,
although it does sort of feel like it is trending in that direction.

~~~
smoothdeveloper
Try paket, will save you a lot of headaches with the redirect stuff

------
crudbug
I am not a .NET developer. But, Core / Framework / Standard nomenclature is
very confusing. Windows and Universal Windows Platform (UWP) also adds further
confusion.

They should explicitly define namespaces :

1\. XAMARIN namespace as cross platform APIs for .NET ecosystem - iOS, macOS,
Android, Linux, may be Web ?

2\. UWP/CASCADE ? namespace for Windows 10 systems.

3\. WINDOWS namespace for backward compatible .NET Framework systems.

~~~
terrajobst
I can see that being a problem. Let me try to explain:

* We've concrete .NET platforms, such as .NET Framework, .NET Core, and Xamarin. They are the moral equivalent of Linux distributions. * With .NET Standard we now have shared specification that dictates which APIs all these platforms have to implement. That's the moral equivalent of POSIX.

~~~
tobltobs
And where does fit UWP into this picture? Or what should I use if I want to
develop apps for Window Store (or whatever the current name is for that).

~~~
Kipters
UWP is a native framework based on COM. Windows 10 apps use .NET Core
(compatible with .NET Standard 1.4) and can access UWP APIs through bindings

------
saosebastiao
This type of standardization is what I like to call Lowest Common
Denominatorism. And it's a leaky solution to a hard problem. The underlying
problem isn't that different platforms have different APIs, it is that
different platforms have different capabilities. Even if you unify the APIs
that are semantically equivalent across platforms, there will always be some
superset of that unified standard that you end up having to use because you
are programming for a platform. At best, the unification makes programming for
a different platform slightly easier and a little more tenable to share some
code across platforms. But your code is still littered with `#if`s everywhere,
and that wreaks havoc on your compiler's (and subsequently your IDE's)
usefulness for catching bad bugs due to platform incompatibilities.

I believe the future of cross platform programming is by integrating Tomas
Petricek's idea of Co-Effects[0] into type systems. While an effect system
tracks what your program _does to the world_ in its type system, a co-effect
system tracks what your code _requires from the world_ , aka the executable's
environment and platform. There are a lot of benefits to this, but the primary
benefit of a co-effect system is that you could safely write cross-platform
cross-compiled code within a single compilation unit project by having
different `main`s that specify and encodify different platform capabilities.
If your `getSDCardFileSystem` function only works on Android because iOS
doesn't have SD card capabilities, then it can't be used in a main function
bound by the iOS context. And if different platforms have similar but slightly
different capabilities, an interface can be defined that shares their
commonalities and is usable across the differing platform executables, while
still making platform-specific code accessible within it's platform specific
executable.

There are other benefits too, but I'll leave that to the reader of [0] if they
want to know more.

[0] [http://tomasp.net/blog/2014/why-coeffects-
matter/](http://tomasp.net/blog/2014/why-coeffects-matter/)

------
khellang
This gist by @davidfowl might make the relationship between the .NET Standard
and .NET platforms more clear;
[https://gist.github.com/davidfowl/8939f305567e1755412d6dc0b8...](https://gist.github.com/davidfowl/8939f305567e1755412d6dc0b8baf1b7)

------
sickbeard
So next year .NET Standard 2.0? Excuse me for being cynical but Microsoft's
track record in regards to versioning isn't great.

~~~
tychuz
And the next year it's .NET Standard One. After that - .NET Standard 10.

------
mrweasel
Hopefully that should help clean up the messy .NET naming. Currently there's
way to many .NET <something> "packages". Microsoft seems to have run amok in
splitting up .NET in minor components, and it has become to difficult to
figure out how everything fits together. Unifying three big block in one
common standard library is a great first move in cleaning up everything.

Now we just need to kill off one of the ASP.NETs.

------
mcs_
I'm still lost. What should I use and when "to go live"? We are small company
with a lot of legacy code that wants to upgrade from 2.0 and 3.5. In 2016.
Which .NET should we use ?

~~~
WorldMaker
Legacy code would probably stick on the .NET Framework (with maybe Mono as an
option to try for some cross-platform reach) for now.

New code is great in .NET Core when you have that option.

If you are building NuGet libraries (which seems doubtful given 2.0 and 3.5,
but possible) you should try to target .NETStandard rather than .NET Framework
or the previous best option PCL. But if you can't target .NETStandard for some
reason, things will get better (soon).

------
jrudolph
@runesoerensen: any plans to offer linux /.net core instances in AppHarbor (my
favourite way to host .net apps by far!)?

~~~
runesoerensen
Thanks for the kind words! You can actually run .NET Core apps already, but
the tooling/CI story is still lagging (primarily because the .NET Core SDK is
still in preview and needs to be updated to the revised .NET Core
project/solution structure).

It's pretty straightforward to publish and deploy binaries from your own
machine until the SDK graduates from preview and betas ("RTM" is expected
later this year) -- take a look at this discussion for more details:
[https://support.appharbor.com/discussions/problems/79972-asp...](https://support.appharbor.com/discussions/problems/79972-aspnet-5-support#comment_40545805)

There are no current plans to offer Linux-based instances, but Windows Server
2016 will be available soon and brings some _very_ exciting and long-awaited
features to the table, that will be integrated in AppHarbor products as soon
as possible. Stay tuned for more information on that :)

------
mohdmasd
I don't understand this bit:

"In order to allow .NET Framework 4.6.1 to support .NET Standard 2.0, we had
to remove all the APIs from .NET Standard that were introduced in .NET
Standard 1.5 and 1.6."

Does this mean that STD 2.0 will support .NET 4.6.1 but not 4.6.2 ?

~~~
terrajobst
It means that .NET Framework 4.6.1 and all later versions will support .NET
Standard 2.0. However, .NET Standard 1.5 & 1.6 will not work on .NET Framework
4.6.1. In other words, we removed the APIs from .NET Standard 2.0 that weren't
implemented by .NET Framework 4.6.1.

~~~
jmkni
And some people say this is confusing!

------
makecheck
Something about their own diagram bugs me: it’s clear that Xamarin covers a
wide variety of targets all by itself so (on the surface) it already seems to
have an architecture that handles new APIs well. Shouldn’t the logical course
be to extend Xamarin and encourage developers to migrate to that?

Given Xamarin code that works on Macs, iOS and Android, _no one_ would call
Microsoft’s layer of peanut butter the API to “rule them all” except
Microsoft.

------
intrasight
They left out what I think is the most important info - when will it ship?
They listed a lot of libraries that aren't yet in .Net Core, but they say that
those will be added to .Net Core to bring it into compliance with .Net
Standard.

------
fail2fail2ban
It sounds like a good track to be on.

~~~
tobltobs
Which of those tracks do you mean?

------
christogreeff
Quite a useful reference article.

------
wodencafe
Nothing about Linux, probably because there is no Linux Consumer Market. Looks
like Microsoft's EEE strategy is alive and well.

This is nothing more than a clever ploy by Microsoft to regain control of C#
from the community, becoming the gatekeeper of the new ".NET Standard"
library... rather than opening up some of their coveted, proprietary codebase.
(Winforms)

TL;DR Micro$oft being Micro$oft

~~~
oblio
> rather than open up some of their coveted, proprietary codebase. (Winforms)

What makes you think that open sourcing WinForms would be any good? It's
probably tied to Windows to the gills.

If anything, they should be doing something else, they should create or even
better, support an existing UI toolkit and promote that as their cross
platform UI.

~~~
terrajobst
While we haven't open sourced WinForms, there is a Mono version of Windows
Forms. We've talked with the Mono guys about it and the general consensus was
that the WinForms API shape doesn't make it very easy for cross-platform.

~~~
oblio
Is there any plan, even a low priority one, for picking up maintenance for
something like Gtk# or Xwt or Eto.Forms? Or for extending UWP or Xamarin.Forms
to Linux?

