
The new ASP.NET Core 2.0 packages can no longer be used on .NET Desktop - ern
https://github.com/aspnet/Home/issues/2022
======
JohnBooty
I moved away from the .NET world less than three years ago and this
announcement might as well be written in Klingon or ancient Greek to me.

Now, keep in mind that I actually thought (and still think?) that .NET and C#
make for a very productive development environment. I didn't leave due to
antipathy; no axe to grind here.

But...

"netcoreapp2.0"? "netstandard1"? "net4"? Huh? What?

From Scott Hanselman's reply:

    
    
       .NET Core is side by side and it’s moving fast. It’s WAY faster 
       than .NET (Full) Framework can move which is good. By building 
       ASP.NET Core 2.0 on top of .NET Core 2.0 (which, remember, is a
       SUPERSET of .NET Standard) that means stuff can be built faster 
       than NetFx or even Netstandard.
    

.NET Core? .NET Full? .NET Standard? .NETfx?

And .NET Core is a _superset_ of .NET Standard? How does that make sense?
"Core" sounds like a stripped-down version of... something? But, apparently
it's a superset. Because nothing makes sense any more.

My only point here is: at first glance, this is an utterly bewildering set of
choices. I'm sure there's a pretty simple relationship between all these
things, but the .NET people probably aren't doing themselves any favors this
these naming choices and (what appears to be) fragmentation between .NET
development targets.

~~~
DougN7
Remember, these are the people that came up with the System32 folder for
64-bit files, and SysWow64 for 32-bit files.

~~~
piaste
It's properly named, because you say "wow..." when you figure it out.

~~~
JBiserkov
It's actually an acronym for "Windows On Windows", but I like your take too :)

------
manigandham
.NET Standard - interface/API definition, not implementation, that specifies
what functionality is supported at what version number.

.NET Framework - older desktop/windows-only that implements the .NET Standard.
Various other smaller frameworks created over the years for mobile, embedded,
etc.

.NET Core - newest cross-platform framework that implements the .NET Standard,
although with less coverage than the full framework because it's new, but .NET
Core 2.0 will have much more in parity and will eventually outpace.

ASP.NET - web framework built on top of the .NET Framework that offers
webforms, mvc, web api, razor views, etc related to making webapps.

ASP.NET Core - web framework built on top of the .NET Core framework that
offers a faster, streamlined pipeline/middleware model with mvc/web api, razor
views, SPA services and integration, etc.

Yes Microsoft is one of the worst companies at naming -- _however_ it makes
perfect sense that ASP.NET Core (the web framework) targets .NET Core (the
underlying cross-platform framework) which itself implements .NET Standard.

It's a case of superset functionality being layered on top. Eventually the
.NET Core code will move faster and outpace .NET Framework, so you will be
able to run .NET Framework libraries inside .NET Core apps but not run .NET
Core apps inside .NET Framework.

~~~
cptskippy
> Yes Microsoft is one of the worst companies at naming

I think you're being too generous. Microsoft branded it's Office Suite, BA
Suite and Operating system .NET once upon a time. They'd have named their own
variety of orange juice OJ.NET if they'd had one.

They __are __the worse company at naming.

~~~
manigandham
Every major company has naming problems from Google to Oracle to IBM and more.
It's just teams, bureaucracy and marketing forces all fighting against each
other.

I do think Microsoft could just hire a VP of Naming who's in charge of all
names and improve productivity by billions but alas, this is where we are
today. However, once the names become familiar, the actual issues are not
nearly as dire as made out to be.

------
jug
I sometimes feel like I need a PhD to understand Microsoft's overarching .NET
philosophy and how it all interoperates. It's strange, because the systems and
what they are supposed to be able to do in terms of computing, human computer
interfaces, and networking is largely unchanged since decades back. What is
going on? Isn't the only major change recently that mobile devices have become
more popular targets and web development is more useful due to web browsers
being cross-platform renderers?

~~~
DanielBMarkham
I hear you, and I feel this pain.

I give up.

I have better things to do.

~~~
windwake12
It's incredibly frustrating. I've been on the .NET wagon since ASP.NET 1.0
(and ASP before that), and my day to day friction with .NET has been
increasing steadily over the last few years as more and more of the eco system
starts to support "core".

Looking over an example doc of how to host .NET in IIS (by far the most common
approach) really shows how out of control it has become:
[https://docs.microsoft.com/en-
us/aspnet/core/publishing/iis](https://docs.microsoft.com/en-
us/aspnet/core/publishing/iis)

It's a mess.

~~~
manigandham
Hosting in IIS with .NET Core is no different than before, it all works the
same. Only difference is that IIS won't be running the code but just acting as
a simple proxy so you turn off the "Managed Code" setting in the application
pool for that site. Than just web-deploy like before and everything works.

All those other settings are settings that were there before.

~~~
tmzt
Does restarting the app pool reload the application? What about changing the
config file?

Is IIS just configuring http.sys at this point? Are modules still invoked
during the request?

------
insulanian
My God, is this ever going to settle down?! I skipped all the .NET Core 1.x
fiasco and decided to wait for .NET Standard 2.0, as it seemed like they
learned the lesson, but now it starts all over again.

~~~
mrweasel
Yeah, as good as .Net is, they really need to work towards a: "Just download
this and everything will work ".

~~~
SideburnsOfDoom
> "Just download this and everything will work "

Ah, the old debate in .Net between the lumpers and the splitters.

Between the "just install .Net and that's it, it makes no sense to install all
these little interdependent pieces one at a time. it's too complex and
versioning is hell" and the "this web server doesn't need the WPF libraries,
it's just dead weight, bloat, and makes it harder to start up new machines. It
makes no sense to bring out a new version of WPF because there's a bug fix in
ASP. Or worse, delay release."

The thing is, there is no one right answer, only opposing forces that have to
be reconciled.

.Net core started out fairly radical, which favoured the early adopters and
neophiles who tend towards splitters, but is now generally veering towards
larger corporate adoption, which tends to wards lumpers. But there are
exceptions.

~~~
dozzie
> Between the "just install .Net and that's it [...]" and the "this web server
> doesn't need the WPF libraries, it's just dead weight [...]"

> The thing is, there is no one right answer, only opposing forces that have
> to be reconciled.

Really? I thought this was a mostly solved problem. I certainly see it as such
when I use modern packaging systems that were developed _almost two decades
ago_.

~~~
SideburnsOfDoom
> I certainly see it as such when I use modern packaging systems that were
> developed almost two decades ago.

I'm not sure if you have something specific to say about the nuget package
management system; how it was used to deliver packages in .Net core and how
and why the strategy has changed from delivering the framework as lots of
small packages to delivering it as few larger packages; or if you are just
being flippant and ignorant.

~~~
dozzie
I would certainly go with ignorant. I stay away from Windows and, in
consequence, from .NET. I've heard about NuGet, but I haven't used it, so I
don't know if it is any good.

On the other hand, I've seen both strategies (large and small packages) in
use, and the better dependency resolution mechanisms and package building
tools, the better small packages work. I don't need to install plethora of
GNOME and Python packages, I just run `apt-get install exaile' and have it
installed. From programmer's perspective this works equally well; I may want
to include some specific part of Boost library, but I can also run `apt-get
install liboost-all-dev' and be done, and leave detecting the actual
dependencies to package builder's tooling.

~~~
lazulicurio
NuGet is okay, in my opinion. My two biggest issues with it aren't actually
issues with NuGet, but with the surrounding ecosystem.

First is that MSBuild hard-codes references, so building a multi-targeted
project with references to a multi-targeted NuGet package is a nightmare. From
what I've read in the documentation, Paket (an alternative package manager) is
supposed to be designed to help with this, but it was already enough of a
struggle to introduce NuGet at my work, and NuGet is "built-in" to Visual
Studio.

Second is the fragmentation of the .NET frameworks, a la this article.
Combined with how .NET makes native interop fairly easy (i.e. platform
dependent packages), you get either bloated monolith packages or a
proliferation of satellite packages.

Other than that, I've had a fairly easy and straightforward time with NuGet.
But then again, I've never seen a project with more than a dozen or so
dependencies, compared to using Maven in Java where you pull in dependencies
like hotcakes.

I'm split. I'd love to see the churn settle down so the surrounding ecosystem
can mature. On the other hand, there are definite pain points with the
existing tooling. I remember seeing declarative package references as a
feature request for Roslyn, which would be absolutely wonderful, but even if
it's released fairly soon, it's probably going to take years for adoption to
spread.

~~~
khellang
> First is that MSBuild hard-codes references, so building a multi-targeted
> project with references to a multi-targeted NuGet package is a nightmare.
> From what I've read in the documentation, Paket (an alternative package
> manager) is supposed to be designed to help with this, but it was already
> enough of a struggle to introduce NuGet at my work, and NuGet is "built-in"
> to Visual Studio.

This has changed radically with Visual Studio 2017 and the newer MSBuild
tooling. See
[https://github.com/khellang/Scrutor/blob/master/src/Scrutor/...](https://github.com/khellang/Scrutor/blob/master/src/Scrutor/Scrutor.csproj#L7)
for an example. It has three targets with both conditional and common package
references.

------
NicoJuicy
This is what Scott Hanselman wrote, please read that first:

==

I can see why this is initially a scary WTF moment. Let me explain because
it’s less freaky than it seems.

You said .NET customers are going to need to interoperate. Totally agree. We
can share netstandard libraries between ASP.NET Core 2.0 and EVERYWHERE. We
can even reference many net461+ assemblies from ASP.NET Core 2.0 because of
typeforwarding and netstandard20 You said WebApps may need to use: AD –
Totally, this is a gap IF you want to call LDAP directly. You can certainly
auth against Windows Auth NOW. We plan to have specifically the
DirectoryServices namespace for Core 2.0 around summer timeframe Drawing –
Totally, this is a gap. We plan to have this for Core 2.0 around summer
timeframe. Until this, these netstandard options also exist ImageSharp,
ImageResizer, Mono options, etc COM Automation – This has never been possible
under Core 2.0, but you can certainly PInvoke if you want to hurt yourself.
You could also local WebAPI to a net461+ process if you really want to hurt
yourself. Sharing code with WFP Apps – YES. Totally possible with
netstandard2.0. This is a weird change to make. Feels like it but… Think about
it this way. WPF isn’t netstandard2.0, it knows it’s on net461+ and that’s OK.
It’s optimized, but it can reference netstandard libs. ASP.NET Core 2.0 is
optimize for Core 2.0 but it can reference shared libraries. Xamarin is the
same.

.NET Core is side by side and it’s moving fast. It’s WAY faster than .NET
(Full) Framework can move which is good. By building ASP.NET Core 2.0 on top
of .NET Core 2.0 (which, remember, is a SUPERSET of .NET Standard) that means
stuff can be built faster than NetFx or even Netstandard.

NetCore > Net Standard > NetFx when it comes to development speed and
innovation.

Point is, if you are doing new work, netstandard20. If you have older net461+
libraries, MOST of those can be referenced under ASP.NET Core 2.0.

ASP.NET Core 1.1 which runs on .NET Framework will be fully supported for a
year after we release 2.0. That workload is fully supported thru at least July
of 2018.

The remaining large gaps missing in .NET Core 2 are System.DirectoryServices
and System.Drawing. We are working to have a Windows compat pack which would
enable both of those on .NET Core on Windows this summer.

What we need from you all is a clear list/understanding of WHY you think you
need ASP.NET Core 2.0 to run on net461+. Be specific so we can close those
gaps and let everyone be successful.

~~~
mattmanser
Easier to read here:
[https://github.com/aspnet/Home/issues/2022#issuecomment-2995...](https://github.com/aspnet/Home/issues/2022#issuecomment-299536123)

How does the reassure you? To me that reads:

 _Boys! We 've been caught. Quick, do Jazz hands and pretend it doesn't
matter!_

That does not seem like a sane response to me. We move fast and break things
_and that 's good_ is not something we should be hearing as a justification at
this point.

And he's making a deal out of it being supported till 2018! A whole year! What
do they think people are making on their framework? Apps that disappear after
a year? Once you commit to a framework you'll be supporting it for 5 or 6
years.

Am I totally misreading it, as to me that is really not a reassuring response
at all, quite the opposite. It seems to me that they've completely lost touch
with their customers who want a stable, fast and predictable new version of
MVC 4.

~~~
dahauns
Same here - this quote sums it up quite well:

 _We built on top of ASP.NET Core because of the option to use it with netfx,
and we built things which were intended to last 5-10 years, not for 1 year of
support max. This is what the ASP.NET name means in business and it 's why
large, slow-moving organisations choose it over flavour of the month
frameworks._

They should take a look at MS history and look back at the Windows Mobile (6)
-> Windows Phone transition for what can happen worst case when you crap all
over your enterprise customers.

~~~
rogihee
Let's not forget the Silverlight debacle too, that made a looooot of
entreprise people unhappy.

~~~
dahauns
And yet, Silverlight is still officially supported until 2021...

~~~
rogihee
Have you tried using it in VS2017? Nowhere to be seen. The runtime is
supported yes, but you try combining and debugging a Silverlight solution with
a .Net Core web app.

~~~
dahauns
Of course - I was actually surprised it still worked in VS2015. I don't expect
it to be forwards compatible. (Hell, we're talking about tech that only runs
in IE11 :) )

But one big difference is: Official support means updates in case of critical
vulnerabilities and guarantees that, at least with IE11, it won't simply stop
working after an update.

ASP.Net Core 1.x won't have any such guarantees after 2018.

And that's kinda hefty when the ASP.NET Core website
([https://docs.microsoft.com/en-
us/aspnet/core/](https://docs.microsoft.com/en-us/aspnet/core/)) still refers
to this page for guidelines as to which .NET Runtime to choose for ASP.Net
Core(!) projects:

[https://docs.microsoft.com/en-
us/dotnet/articles/standard/ch...](https://docs.microsoft.com/en-
us/dotnet/articles/standard/choosing-core-framework-server)

------
noir_lord
I was really hoping for F#/.net (core) on Linux to be a thing but at this
point I'm so confused about the versioning it makes my head hurt.

At least over in JVM land things are somewhat clearer.

~~~
enricosada
See [https://github.com/dotnet/netcorecli-fsc/wiki/.NET-Core-
SDK-...](https://github.com/dotnet/netcorecli-fsc/wiki/.NET-Core-SDK-1.0.1)
for quickstart and info for F# on .NET Core.

VSCode (with ionide), vim (vim-fsharp binding), emacs (fsharp-mode) already
support it, with full intellisene. VSCode also support debugging.

About the aspnet stack, same future limitation of C#, as discussed on the
post. But there are also alternative web stack, like Suave.

~~~
noir_lord
Thanks, I'm aware of that as a resource.

That isn't the issue, the issue is that when I play with things I restrict
myself to playing with things that I can potentially use in production at some
point, I don't have a lot of 'play time' so it makes sense to prioritise
things that have a potential return.

------
bad_user
This reminds me of Rich Hickey's keynote called "Spec-ulation":
[https://www.youtube.com/watch?v=oyLBGkS5ICk&t=0s](https://www.youtube.com/watch?v=oyLBGkS5ICk&t=0s)

He's classifying changes in library as either:

    
    
        - (backwards compatible) growth
        - breakage
    

He's also saying that "semantic versioning" is a recipe for breaking people's
software and that if you're going to break things, then you should change the
name / namespace. I agree with him.

~~~
Chyzwar
Problem is not semantic version but .Net platform that have multiple branches
of the same thing[0]. If MS was not braindead they would promote Mono to
become .Net Core instead of building a new thing.

Hickey's Clojure introduce breaking changes even in minor versions[1] how this
is more sensible?.

[0][https://docs.microsoft.com/en-
us/dotnet/articles/standard/li...](https://docs.microsoft.com/en-
us/dotnet/articles/standard/library)
[1][https://github.com/clojure/clojure/blob/master/changes.md](https://github.com/clojure/clojure/blob/master/changes.md)

~~~
bad_user
Even though its history isn't perfect, Clojure's changes are not breaking and
it's one of those projects that sets a high bar for what backwards
compatibility means.

Clojure code written for 1.0 (May 2009) works just fine in Clojure 1.8 and
you'd find it challenging to find an item in that linked document that
actually breaks compatibility.

------
kayoone
I recently started a new project in .NET Core because i really like C# (mostly
from working with Unity) but i am pretty sure that i won't use it again for
some time. I naively believed i could now use the .NET ecosystem on a small
microservice running on linux, but i quickly learned that support for .NET
Core has to be actively built by maintainers of libs and the current choice
isn't great, documentation is lacking and there is a lot of confusion like the
issue linked to here or the whole project.json vs csproj debacle.

~~~
m_fayer
I use NancyFX on the old .NET/Mono for that purpose and it works well. I keep
hoping to switch to Core and it keeps not happening, but the old way seems to
have a lot of life left in it.

------
pjmlp
Better wait until they make their minds and keep on using .NET Framework, it
seems.

EDIT: Replaced .NET Desktop with .NET Framework, which is more accurate.

~~~
jug
This is what we're doing. Using .NET Framework and not having to pay energy to
following this the past three years has been truly liberating. It's an as
powerful framework as ever, perfectly suitable for modern web development and
whatnot. Yes, you miss out on cross platform support from .NET Core, but I
feel like that hasn't even begun taking off yet and I'd argue that using e.g.
Go or Python might make you a happier human being in that case anyway, or at
least with a more peaceful, productive state of mind.

~~~
piaste
And if you need cross platform support, Mono is likely to be significantly
less trouble than .NET Core 0.2, whoops I meant 2.0 sorry.

~~~
WorldMaker
A increasing amount of Mono _is_ .NET Core. The wonders of open source is that
you can do the effort once and share it. Eventually there will be no Mono,
only .NET Core.

------
styfle
We wrote a .NET Core microservice a few months back and there were problems
upgrading from 1.0 t 1.1 (or some minor point like that). I scraped it and
rewrote it in node.js and now looking at this, I'm glad I did it.

I just don't see .NET Core having any stability. Meanwhile, node just landed
promises in core[0] a few minutes ago.

[0]:
[https://news.ycombinator.com/item?id=14299623](https://news.ycombinator.com/item?id=14299623)

------
bhrgunatha
I understand what .Net standard and .Net core are but I think they need a
better strategy for their nomenclature that using .Net in the name of every
runtime, platform and set of libraries.

------
mariusmg
The first thing they need to change for .Net Core is the name. "Core" is such
a meaningless term. Call it something like .Net Multiplatform or something.

------
kierenj
From the comments, the title seems misleading - the only issues are with
System.Drawing and System.DirectoryServices. Am I misunderstanding?

~~~
mythz
The issue is about Microsoft having just decided to drop support for being
able to run ASP.NET Core 2.0 on the full .NET Framework. The current plan is
to drop support for .NET v4.x after the current ASP.NET Core 1.x release:

[1]:
[https://github.com/aspnet/Home/issues/2022#issuecomment-3000...](https://github.com/aspnet/Home/issues/2022#issuecomment-300043783)

------
j_s
> _Although this major breaking change is likely to have a huge impact on the
> entire ASP.NET ecosystem, it was neither discussed nor announced publicly_

Microsoft, although demonstrably more open-source friendly, still moving the
cheese.

------
merb
well I think a big minus in the ecosystem is that many projects (including
something popular like NHibernate) actually pulled themselfs too much into the
framework, they didn't created their own (which of course wasn't/isn't bad)
but it tangled it, with a lot of implementation from microsoft (which
microsoft now breaks). I always was very curious why that happened. I mean
.NET has something like DataTable/DataReader, classes that were fully!!!
implemented. In Java for SQL access you just gotten some interfaces and a
Socket, the rest was up to you. (and somehow that worked, we have drivers for
every major database in Java). Actually besides some
java.io.InputStream/java.io.Reader there weren't such high level classes
used/are used in these drivers. I mean since java8 we now have some nio
classes that makes byte manipulation a lot of easier, but most stuff is still
implemented by the driver and not any framework at all. (even
ResultSet/Connection/DataSource is just an interface)

~~~
pjmlp
Usually the culture on the .NET side of the fence tends to be more practical
code oriented for quick solutions to daily use cases, than the enterprise
solutions targeted to every possible use case one might eventually encounter.

I love working on both sides, but sometimes we get into these kind of issues.

On Java side I never liked that Sun engineers never grasped the expectations
of what being a desktop developer actually means (AWT, Swing, Java 3D, JAI,
JDI...). Which is an area, where Oracle actually managed to handle slightly
better, but lets see.

~~~
UK-AL
I find that strange since some of the most popular "enterprise" patterns in
use were made popular in .net. CQRS/EVENT SOURCING/DDD

~~~
pjmlp
I never used any of those, and I have been in the enterprise since the
mid-90's.

The only .NET enterprise pattern I can relate to is MVVM.

~~~
UK-AL
I'm seeing these patterns being referenced a lot more in java and node
conferences recently.

------
iask
I also find this extremely confusing, even after using .NET since 1.0.

I wish they would make a chart, diagram...call it what you may, on MSDN or the
Github repo, indicating all the frameworks, a description and what developers
should target when using one e.g. Desktop, Web or API, Mobile, Cloud etc.

That way, when comes the time to develop an app, we reference the chart and go
from there.

~~~
equasar
There's already one: \-
[https://blogs.msdn.microsoft.com/dotnet/2016/09/26/introduci...](https://blogs.msdn.microsoft.com/dotnet/2016/09/26/introducing-
net-standard/)

------
Sir_Cmpwn
I actually quit using .NET entirely because Mono is a trainwreck while this
stuff is being sorted. Half of the libraries I'm used to spewed esoteric
errors about framework mismatching and such last time I tried. The new stuff
from MS is difficult to use except on a few blessed Linux distros and Mono is
slow on the uptake.

------
dep_b
As a .net Developer this also doesn't make much sense to me. I do know that I
can keep firing up Visual Studio and keep working on my existing applications
without this stuff hurting me. Also switching between .net versions will be
fairly painless since they're all really similar. The only hard thing is
understanding if you can port legacy app x to new stack y.

Nothing that would stop me from using .net.

Microsoft is really good to keep developers dangling. Can / should I still use
WPF? Did it secretly continue under a different name?

~~~
WorldMaker
This issue seems to mostly be (healthy) debate on that "can you port legacy
app x to new stack y" front. It should (eventually) resolve to most people's
satisfaction, but the sausage is being made in public on GitHub and that's new
and frightening to some .NET veterans.

«Can / should I still use WPF? Did it secretly continue under a different
name?»

You can still use WPF if you are happy with it. The Universal Windows Platform
(UWP)'s .NET/XAML stack is the relatively open and acknowledged successor to
WPF. It should be quite familiar to existing WPF developers and offers some
nice new features and performance. Porting to UWP is still sometimes tough
from WPF, but Project Centennial/the Desktop Bridge can make it a lot easier
to do the transition a piece at a time.

------
jamescostian
I started using .NET for one, and only one reason: interop. Now that they're
gutting interop, I want to jump ship, except there aren't any alternatives!

------
tekism
They should allow the community to vote on naming these products, they have
done a terrible job at it.

~~~
svaha1728
My votes would be:

Bloaty McBloatface - .NET Standard

Fleabiscuit - .NET Core

------
kodfodrasz
This seems like FUD to me. (just skimmed the thread on mobile)

First, this is about a preview version only.

Second: Moving Asp.Core 2.0 target to Netstandard 2.0 is a sensible step to
me. This version will be supported by desktop .Net 4.7 (win7+) when the
standard is RTM. This will be the point where depending technologies will be
RTMd as well. We should revisit this discussion then.

~~~
mythz
> Moving Asp.Core 2.0 target to Netstandard 2.0 is a sensible step to me.

Read the issue carefully, they've done the exact opposite and have started
changing ASP.NET Core 2.0 packages from targeting .NET Standard to now only
target .NET Core netcoreapp2.0 so they will no longer be able to be referenced
from the full .NET Framework.

They've also just announced that ASP.NET Core 1.x will be the last version
that will be able to run on the Desktop CLR:

[1]:
[https://github.com/aspnet/Home/issues/2022#issuecomment-3000...](https://github.com/aspnet/Home/issues/2022#issuecomment-300043783)

~~~
flukus
Doesn't that make sense? Why would you want to run a core 2 app on the desktop
CLR instead of distributing a binary? Not having suitable replacements for a
lot of existing libraries is the bad part.

~~~
mathw
The issues people have with the move largely revolve around applications that
need .NET Framework (such as WPF applications) which embed network servers
currently built on ASP.NET Core 1.x, which runs happily in that scenario, but
2.0 won't and 1.x support isn't going to be around for more than a year after
2.0 drops.

WPF will probably never work on .NET Core, so after that they're going to have
to have some kind of elaborate multiprocess solution if they want to stay in
supported versions.

~~~
cm2187
But also all the third party libraries. Very few run on .net core.

~~~
WorldMaker
.NET Core 2.0 should run most libraries from every verson of the .NET
Framework 1.0 to 4.6.1 (and potentially higher), with very few exceptions
(albeit in some cases literally exceptions). (That's all the work that has
gone into defining the .NET Standard 2.0 API.)

