.Net Standard 2.1?

[RussKeldorph]

From @jherby2k on March 7, 2018 19:35

I can't find any information about a .net standard 2.1.

I really want to use the new Span-ified methods like Stream.Read in my class libraries, but it looks like that stuff isn't in System.Memory but rather the .net core 2.1 SDK. Any other way to get these APIs, or do I have to wait for .net standard 2.1. And is there any ETA on that?

Copied from original issue: dotnet/coreclr#16806

[RussKeldorph]

From @danmosemsft on March 8, 2018 0:0

@ahsonkhan are these in OOB packages?

[RussKeldorph]

From @ahsonkhan on March 8, 2018 0:15

I really want to use the new Span-ified methods like Stream.Read in my class libraries, but it looks like that stuff isn't in System.Memory but rather the .net core 2.1 SDK. Any other way to get these APIs, or do I have to wait for .net standard 2.1. And is there any ETA on that?

You do not have to wait for them to be added to .net standard 2.1 if your applications can target .NET Core 2.1.

are these in OOB packages?

The System.Memory package (which contains Span/Memory/etc) is available OOB (for full framework and older version of .net core (like 2.0), and it complies with netstandard1.1 so can be used on any of the platforms that meet netstandard1.1+ spec.

The new overloads being added throughout the BCL, like the Stream methods, as part of the "Spanification," are only available starting on .NET Core 2.1, as far as I know. So those ones are not in OOB packages.

I can't find any information about a .net standard 2.1.

Can you help address this, especially if I missed something? cc @terrajobst, @KrzysztofCwalina, @stephentoub

[RussKeldorph]

From @jherby2k on March 8, 2018 3:39

But i'm writing a class library, not an application, and targeting .net standard as per Microsoft's recommendation. So if i want access to these Stream APIs (my library does a ton of file IO and parsing) i'm pretty much going to have to wait indefinitely, or target .net core 2.1 and forgo netfx support? Disappointing.

[RussKeldorph]

From @Joe4evr on March 8, 2018 7:3

But i'm writing a class library, not an application, and targeting .net standard as per Microsoft's recommendation.

Yes, I've been wondering myself why there are methods in netcoreapp that aren't available in the equivalent netstandard TFM. Basic things like [ConcurrentQueue<T>.Clear()](https://apisof.net/catalog/System.Collections.Concurrent.ConcurrentQueue%3CT%3E.Clear()) not being available in any .NET Standard (while [ConcurrentStack<T>.Clear()](https://apisof.net/catalog/System.Collections.Concurrent.ConcurrentStack%3CT%3E.Clear()) is available everywhere) is what boggles my mind the most.

[davidfowl]

Even if there was a netstandard 2.1 the only thing that would implement it on day one would be .NET Core. It takes time for new standards to be implemented so regardless so I’m not 100% sure what your nuget package was going to run on in the short term anyways.

[jherby2k]

Well, yes. Another way of phrasing my question would be “when will spanified APIs make their way to full framework?” It sounds like there is no plan to do so, which is very disappointing given the enthusiasm Microsoft displayed when announcing this stuff.

[bartonjs]

@jherby2k Right now we're focused on successfully delivering .NET Core 2.1 (including the Span work). So while it may be fair to say that "there is no plan" it's more that "no plan has been made" (as opposed to "we plan to not do it"). So I'd amend the statement to be "there is no plan yet".

[arkadiuszwojcik]

Link to related mono project issue mono/mono#6845

[charlesroddie]

Most people would assume that new stuff that goes in .Net Core will also get put in .Net Standard and that the version numbers are in sync, so that new stuff in .Net Core 2.1 will go in .Net Standard 2.1. This is just so natural that it would be a working assumption of .Net users, and presumably also of people working on other .Net platforms and on .Net Core itself. Please tell us if that's not the case. If it is the case then it's a de facto plan already, just awaiting official confirmation and scheduling.

[markrendle]

While the only implementation that supports the Span APIs is .NET Core, it doesn't make sense to have them as part of any standard. As soon as another implementation adds support, whether that be .NET, Mono, Xamarin or whatever, then there is a need for a Standard profile to cover it.

The counter to that, I suppose, is that since other implementations adding Span support is pretty much a given, it's annoying that we're currently publishing NuGet packages tied to netcoreapp2.1 and will have to republish when netstandard2.1 becomes available.

Having watched a couple of API reviews over streams, though, I do understand why the work needed to add them to a Standard is being deferred until Core 2.1 is released :trollface:

[devsko]

Are the new APIs available on UWP (6.1 or whatever version)? If they are, it is a good reason for a .net standard 2.1. If not, its very disappointing.

[jherby2k]

I know that .NET standard was kind of retrofitted over the current frameworks, but going forward, shouldn't the standard be established first? I mean, if its truly a specification, shouldn't the specification be agreed upon prior to implementation? It would also give non-MS implementations (i.e. mono) something concrete to target for their future releases.

[fredericDelaporte]

Same issue for me, but looking for System.Runtime.Caching (ported to core2.1, dotnet/corefx#14529) for extending tagets supported by a library (nhibernate/NHibernate-Caches#38). I would rather add a netstandard2.1 target than a netcoreapp2.1 target, even if at first only .Net Core will implement it.

[stakx]

This issue makes for a very sobering read.

I dare say that the new Span<T> and Memory<T> APIs are going to be deal breakers for many people in many circumstances.

If they are only available in .NET Core for any extended period, then quite frankly what's the point in using .NET Standard, or the .NET Framework for that matter, any longer? These types are fast becoming a cornerstone for high-performance code, and I for one want to use them in my libraries. Hence I'm forced to target just netcore2.x in order to do so.

Alternatively, I won't use these new types in my code at all (just by themselves, without supporting APIs, they are about as useless as ArraySegment<T> was) and continue to use .NET Standard to automatically multi-target my libraries to several platforms. (That for me is the more preferable goal, over putting performance first.)

But there's no viable third way in my opinion. What I expressly don't want to do is to go back to manually multi-targeting different platforms, sprinkling #if FEATURE_SPAN_APIs across my whole code bases (libraries), and writing alternate code in the #else using traditional APIs in order to support Span-less platforms. .NET Standard (esp. version 2) was supposed to rescue us from having to maintain this kind of mess.

The new types, along with the C# 7.2 language enhancements, the JIT improvements, and the new APIs are hugely promising for performance and have been clearly advertised as such. Also, the barrier to entry was made to appear appealingly low by having the System.Memory package target .NET Standard 1.1. This alone suggested that JIT improvements and APIs would soon be added to the .NET Framework, too.

And now all of a sudden the word is that these new APIs are .NET Core 2.1 only for the foreseeable future?

That strikes me as either bad communication, or a very dissapointing decision.

[stakx]

@fredericDelaporte said:

I would rather add a netstandard2.1 target than a netcoreapp2.1 target, even if at first only .Net Core will implement it.

Exactly, doing so means that library authors don't have to go back, add more targets, and recompile once more platforms support the feature / API. A library will just magically support more platforms once they catch up and implement the given .NET Standard API.

That's a huge benefit to library authors, and the reason why Span and Memory APIs should become part of .NET Standard soon.

[fredericDelaporte]

System.Runtime.Caching may not be a good example, as it appears to be already available for netstandard2.0 as an additional preview dependency. Same for Span<T> indeed. So even if they will not be in the standard, they should still ends up usable in libraries targeting the standard, provided they take some additional dependencies.

[gehnster]

Any update on when .NET Standard 2.1 would come out? Also what features will it have that .NET Core 2.1 has? Specifically I'm looking forward to the HttpClientFactory and new Status Codes. If they aren't going to be a part of .NET Standard then I might as well switch over to .NET Core 2.1 now for the class library I'm working on.

Thanks

[SidShetye]

To add, it makes more sense to first agree on a standard and then follow that up by implementations.

Also, it's confusing to download dotnet sdk 2.1.200 but it doesn't support .net core 2.1 (just 2.0). One has to get dotnet sdk 2.1.300 to get .net core 2.1.

dotnet versioning is getting more complicated than it really needs to be.

[dasMulli]

@sidshetye see the version proposal at https://github.com/dotnet/designs/pull/29/files?short_path=579bdc1#diff-579bdc17733868e490e711c1245bb183

TL;DR the switchover to 2.1.* for the SDK happened and it's impossible to go back in time now. In the future, major nad minor version numbers of the SDK are going to match the .NET Core runtime version. So the first SDK supporting .NET Core 2.2.0 will be 2.2.100.

[BowserKingKoopa]

With the release of .NET Core 2.1 I went looking for info about .NET Standard 2.1. I didn't expect to find this.

"While the only implementation that supports the Span APIs is .NET Core, it doesn't make sense to have them as part of any standard. As soon as another implementation adds support, whether that be .NET, Mono, Xamarin or whatever, then there is a need for a Standard profile to cover it."

That is not how I expected .NET Standard to work. I expected it to lead the implementations (or probably to stay in sync with .NET Core since that seems to be the "primary" .NET implementation these days). This makes me feel a little like I'm reading .NET Standard's tombstone. I now fear it's always going to be a little neglected.

It certainly means Microsoft's recommendation that libraries target .NET Standard is no longer correct.

[davidfowl]

It certainly means Microsoft's recommendation that libraries target .NET Standard is no longer correct.

How is that the conclusion here?

[TAGC]

How is that the conclusion here?

Well it means that libraries have to target .NET Core specifically instead of .NET Standard if they want to use these new APIs, right?

[davidfowl]

That's correct. If you want to use APIs that are only available in .NET Core then you have to target .NET Core. Span/Memory etc work in .NET Standard 2.0 applications though so they can be exposed without targeting .NET Core.

Now I agree to take full advantage of them you need to cross target to .NET Core 2.1 but I think the only difference here right now is that you have to cross compile for ns2.0 and netcoreapp2.1 if you want to expose APIs with Core APIs with Span in them (like a custom Stream) or use the netcoreapp2.1 APIs in your package implementation (this doesn't really bleed out).

ASP.NET does this today. We use Span and memory in a bunch of implementation and we also expose it in some tactical places where it improves the performance. You can absolutely expose first class APIs without yourself being cross compiled though.

[arkadiuszwojcik]

@davidfowl but what is current perspective on this? Is .NET Standard 2.1 something possible after Mono will pair with .Net Core codebase? Or more realistic is to wait for .NET Standard 3.0?

[BowserKingKoopa]

@davidfowl My previous understanding went something like this: .NET Standard represents .NET. If you want to target .NET, then target .NET Standard. The latest version of .NET Standard represents the latest and greatest .NET. It does NOT represent the lowest common denominator. (Lowest common denominator would be the version of .NET Standard you need to target to get on to all the platforms you want to get on to).

But this thread makes it sound like the latest version of .NET Standard does indeed represent the lowest common denominator. .NET Standard isn't .NET. Rather, .NET Core is .NET and if you want to use the latest greatest .NET you have to target .NET Core. .NET Standard will stumble along behind somewhere perpetually out of date.

Doesn't this take us away from the idea of One .NET (.NET Standard) and many implementations of it back to one the old days of One .NET (.NET Core, or in the old days .NET Framework) and some weird out of date offshoots.

But why? Why not take these nice new APIs and Types, tie a bow around them, and call them .NET Standard 2.1? That's what I thought was going to happen.

[davidfowl]

If we rev the standard at the pace of the fastest platform, doesn't that defeat the purpose?

[TAGC]

I don't think so. Like others have pointed out, releasing the standard first means we can continue to target only NET Standard and not any particular runtime for our class libraries, as well as firmly establishing the targets that other platforms need to achieve to "catch up" with the fastest platform.

Those are some of the advantages. I don't see any disadvantages in releasing a standard that only one platform initially implements. My expectation would be for .NET Standard 2.1 to be released concurrently with .NET Core 2.1 and then eventually some future .NET Framework version comes along that implements .NET Standard 2.1 as well.

[chrisdpratt]

I think a lot of the disagreement here boils down to a fundamental confusion about .NET Standard and .NET Core. Up until .NET Standard 2.0, Core was a limiting factor. Its API footprint was so small that the cross-target API had to basically conform to what Core provided. What you're seeing now is Core maturing and taking on it's own development arc. Just as .NET Framework, Xamarin, Unity, etc. can all add their own unique APIs that .NET Standard doesn't necessarily need to support, Core too can do it's own thing. If you want something in Core only, then you must target Core. This is no different than any of the other frameworks. If you want something that only exists in Unity, is it correct to complain that it's not part of .NET Standard? No, of course not.

Long and short, if you want to target .NET Standard, then you must accept that you can only use those APIs that exists everywhere. If you need something specific, then target what you need.

[stakx]

(Warning: This is going off a bit on a tangent. I don't think the discussion should go in the direction I'm taking here, but I'd nevertheless like to mention this as another possible implication of the present issue.)

@chrisdpratt: Well said. I do agree, but the thing is that ever since the ascent of .NET Core, the classic .NET Framework has been neglected. Sure, .NET Core can do its own thing and that's fine... but .NET Framework doesn't appear to go anywhere anymore these days. All the innovation is now appening on .NET Core. What I am worring about is that this innovation is not going to trickle back to the .NET Framework at a useful rate, and especially now that UI desktop framework support has been announced for .NET Core 3.0, I can see how the full Framework has begun its slow death march. The apparent unwillingness to add major new APIs to .NET Standard appears to confirm that this is indeed happening, and it's actively accelerating this development by pushing people away from supporting .NET Framework. (Advancing .NET Standard, OTOH, would be a cue that there's a plan to implement the new APIs on different implementations. And that cue is missing right now.)

My view here is of course very limited. There are other .NET implementations besides .NET Core and .NET Framework, TBH I simply don't know them well enough to make a more general statement.

[svick]

@davidfowl As I understand it, one of the points of .Net Standard is to make writing libraries easier. The idea is that you just target the "right" version of .Net Standard based the APIs you need and target frameworks you need to support. But if I want to use an API that's in .Net Core now and will be in .Net Framework in the future, there is no version of .Net Standard I can target.

Instead, I have to target .Net Core 2.1 now, presumably multitarget .Net Core 2.1 and .Net Framework vNext some time later and finally switch to targeting .Net Standard vNext after that.

I think this approach is not making the life of library developers easier. It's effectively discouraging them from adopting new features.

Also, it doesn't necessarily have to be as fast as the fastest platform. But I think that being slower than the slowest platform is not the right pace either.

[svick]

@chrisdpratt This is not about APIs that are .Net Core-specific. It's about APIs that are currently only in .Net Core, but will be included in other frameworks in the future. I think it makes sense to include such APIs in a new version of .Net Standard, even if those other frameworks don't support the APIs just yet.

[gehnster]

So, if I understand this correctly, and based on this article. Are you saying that .NET Core 2.1 uses .NET Standard 2.0 as its foundation and just implements additional features beyond what is in .NET Standard 2.0?

So for example, I'm looking to use the new HttpClientFactory. I figured it would be in .NET Standard 2.1 since the shared common library I was creating targets .NET Standard 2.0 and that seemed to be the move Microsoft was pushing for us to do. Instead though HttpClientFactory is just going to be a feature of .NET Core 2.1, but it was built off of what was in .NET Standard 2.0? So really, I should having my shared library targetting .NET Core 2.1 instead of .NET Standard. Is that correct? I imagine the same thing will go for the new Http Status Codes being added.

[gehnster]

Another question based off this page. What would the table on that page look like after .NET Core 2.1 is released? I also noticed the paragraph under the .NET Standard Versioning Rules header for the Immutable bullet point. Probably worth reading for everyone in this discussion that what David mentioned has been their intent for .NET Standard for a while.

[Petermarcu]

@gehnster I don't think the table changes. The table says that .NET Standard 2.0 is supported in .NET Core 2.0 and higher. The table says the version for each platform where a specific version of .NET Standard support was added.

[stakx]

@svick:

Instead, I have to target .Net Core 2.1 now, presumably multitarget .Net Core 2.1 and .Net Framework vNext some time later and finally switch to targeting .Net Standard vNext after that.

Exactly. And as a library author, you can't actually afford to target only .NET Core initially. So either you don't use the new APIs until they're more widely available, or you write code twice and have lots of #if FEATURE_X stuff.

[BowserKingKoopa]

@stakx I feel the same way. That's why I called this ".Net Standard's tombstone". Microsoft never announces the end of something. They just ignore it until it goes away (moment of silence for Silverlight, XNA, and .NET Framework). You often have to read between the lines. That's what this feels like. Maybe .NET Standard was just a way to smooth over the migration from Framework to Core and will be neglected and eventually forgotten about. The changes in .NET Core 2.1 that we're talking about here seem like no-brainers for inclusion in Standard (we've already got these cool new memory types, lets update some APIs to actually use them). If Standard was healthy they'd have a 2.1 ready to go already. Even a 'it's coming soon be patient' would be something. I did not expect 'just target Core'. My Microsoft spidey sense is tingling.

[svick]

@gehnster As far as I can tell, HttpClientFactory is an ASP.NET Core feature, which means it's supported on .Net Framework.

Specifically, the Microsoft.Extensions.Http package targets .Net Standard 2.0. And the primary sample in the HttpClientFactory repo targets .Net Framework 4.6.1.

[stakx]

My Microsoft spidey sense is tingling.

I couldn't have said it any better. 🤣

[svick]

@stakx Maybe I'm writing a brand new library and I'm okay with only supporting .Net Core for now, but would like to support .Net Framework once it gets the APIs I'm relying on.

Or, if I am multi-targeting, I would like to muti-target versions of .Net Standard, to make my targets easier to manage. I don't want to keep switching which frameworks I target when the APIs I'm using don't change, only their support in frameworks. Also, I'd prefer to have a linear set of NETSTANDARD_x.y_OR_NEWER defines, instead of having to maintain a number of FEATURE_x defines.

[KrzysztofCwalina]

I think we should consider developing an adaptive NuGet package with set of adapters/helpers that would allow people to write portable code, and then slowly transition to Net Standard when these new APIs become available there. For example, if you want to call Stream.Read(System.Span<byte> buffer), you would have to temporarily call:

// pseudocode
public static class SpanApiAdapters {
    public static int ReadAdapter(this Stream stream, Span<byte> buffer) {
        #if CORE
             return stream.Read(buffer);
        #else
            byte[] pooled = ArrayPool<byte>.Shared.Rent(buffer.Length);
            int read = stream.Read(pooled);
            pooled.AsSpan(0, read).CopyTo(buffer);
            ArrayPool<byte>.Shared.Return(pooled);
            return read;
        #endif
    }
}

[davidfowl]

IMO we shouldn't be making a new standard until platform owners agree on what goes into it.

@KrzysztofCwalina that doesn't work for all things. There are static methods that were added.

[KrzysztofCwalina]

For static methods we would do:

public class SomeTypeAdapter {
    public static ReturnType SomeMethod(...);
}

instead of calling

public class SomeType {
    public static ReturnType SomeMethod(...);
}

or something like that. The point is that we would write the ugly #if deffed code once in a helper package ass opposed to everybody having to sprinkle their code with the if defs.

[chrisdpratt]

@svick: That may be the plan, i.e. adding these new .NET Core features into .NET Standard, but it's important to realize that each of these things has it's own development timelines. If Microsoft goes ahead and release .NET Standard 2.1 with support for a bunch of .NET Core 2.1 new features, it may seem like it doesn't affect anything because people can just keep targeting .NET Standard 2.0 for other situations. However, now, everything must eventually release these features before they can become .NET Standard 2.1 compliant. If that's impossible or not feasible for certain other frameworks, then either they get permanently stalled at 2.0 or you'd have to rollback the support of that feature in 2.1 (which you can't really do at that point because there's dependencies). In other words, Microsoft must be very choosy about what goes into a .NET Standard release, and generally, that means waiting until features are already universally supported. That's in fact how every release of .NET Standard has proceeded thus far, and I don't see that changing.

@BowserKingKoopa: That's not the situation at all. For one, .NET Standard is relatively new, so I find it highly doubtful that Microsoft is already considering changing course. Second, they're still actively promoting using .NET Standard, which they would not do if they had intentions on moving away. Again, this the result of a misunderstanding of its purpose. The development timeline is intentionally slow and deliberate. There should only be a new release when all the Microsoft frameworks push forward. It's all about targeting the least common denominator of functionality. You're trading bleeding edge for compatibility. You can just as easily choose bleeding edge and target something like .NET Core, but if you want the compatibility, then you must adjust your expectations accordingly.

[stakx]

In other words, Microsoft must be very choosy about what goes into a .NET Standard release, and generally, that means waiting until features are already universally supported.

As a consequence, library authors who want to leverage .NET Standard must also be very choosy about what new features they use, and generally, that means waiting until features are universally supported.

So why the big early fanfare (blog posts, magazine articles, etc.) about Span and Memory when these aren't ready for widespread use? If Microsoft wants people to adopt the new features, (IMHO) they should implement it in more platforms than just .NET Core... and only then start the fanfare.

I'll keep in mind from now on that .NET Standard is best better seen as the lowest common denominator of .NET implementations, instead of seeing it as their specification. I suppose this will prevent further disappointments in the future.

(I do not want to appear ungrateful. Span and Memory are great, no question about it. And for those people who are restricted to .NET Core for whatever reason, it's a great new tool available now. But for others, the current situation is potentially frustrating. It's a pity that Microsoft doesn't make a more concerted effort about the whole .NET ecosystem. Things are so fragmented these days, no wonder people are confused and misunderstand. This really could have been communicated better.)

P.S.: Here's the definiton for .NET Standard from https://docs.microsoft.com/en-us/dotnet/standard/net-standard. I see now that it's actually very accurate, but it's too easy to only read the first part and gloss over the second (emphasis added by me):

The .NET Standard is a formal specification of .NET APIs that are intended to be available on all .NET implementations.

(Obviously, that intention can change over time, so while it is a specification, it's not meant to be one that necessarily has to precede the implementations.)

[BowserKingKoopa]

"I'll keep in mind from now on that .NET Standard is best seen as the lowest common denominator of .NET implementations, instead of seeing it as their specification. "

Here lies .NET Standard. We hardly knew you.

[gulshan]

IMHO, .net standard should have been built on CLR capabilities, not the extent of BCL implementation. Then new compiler and BCL features would just declare required level and single implementations could be used on all platforms.

[SidShetye]

This is not straight forward for library authors. The fact that .NET standard/core/framework/sdk are managed by different teams should be abstracted away from the eco-system. We're underway porting to .NET Standard but now, to borrow from above, our spidey senses are tingling :(

To me a standard is a specification or blueprint. So now ...

• .NET Core has it's own standard + implementation
• .NET Framework has it's own standard/spec + implementation
• .NET Standard is trying to be THE standard by herding the cats

[davidfowl]

@gulshan can you elaborate? How would that work? How does that fix any of the mentioned problems?

@sidshetye the problem isn’t possible to make things “simple” things will always leak to library authors.

One of .NET’s major strengths is what also makes it hard for library authors. We have many implementations .NET and we don’t control the deployment of all of them. The .NET team also doesn’t control the pace at which each of the frameworks within our control ship (for e.g UWP ships on Windows). .NET standard tries to remedy that by picking a core set of APIs that must exist everywhere.

The more we change existing types within the standard, the more we have to rev it. The higher the standard you support in your library the less platforms you’ll run on, that’s why the guidance is usually to target the lowest standard (though I would recommend everyone pivot to netstandard 2.0 as the new baseline). This is also why we generally avoid adding things to the standard willy nilly. The more things that exist in the standard the harder it is to push everywhere.

Of course the other extreme to that is to freeze the standard and ship everything new as packages on top but that isn’t the plan of record either, we think there’s a middle ground.

Would you rather us just put out standards that didn’t run anywhere but .net core for however long that ended up being the case and things end up in other platforms when they get there?

[John0King]

I have a idea of this , but I don't know if it is possible.
current .net standard is just a api surface standard( this is good), I'm kinda agree @gulshan .net standard should have been built on CLR capabilities , but it may still not enough for library authors (CLR capabilities might can be simulate). luckly for us, anything in .net is nuget package now, why can't we take advantage of this, make the .net standard indeed the api surface of the core dotnet , but not limited by the framework implement, if the framework has the lower version of an assembly ,then the application will download the newest assembly/package from nuget and use the newer version, and .net standard can keep update , library authors can only target the latest .net standard, and anything still work for older framework (this may make FDD became the SCD if the standard too ahead than the framework, for example if a lib target .net standard 5, and your app target .net core 2.0 , the FDD might produce same ouput than SCD, any assembly will from .net standard 5) , and this can solve the Span<T> and Stream.Read/Write problem , and the only problem will be : how to design NETStandard.Library

[davidfowl]

I can’t even begin to explain why this is much much more complicated than doing just that. I actually don’t know what you mean when you say that .net standard should be built on CLR capabilities. Can you clarify what that means concretely?

I think what you’lll find if you dig into specifics it falls apart quickly if you look at how .NET works.

The amount of bugs that we end up having to deal with because we have components that are packages on one platform but are “built in” to another platform is extremely high. Each runtime has their own different set of versioning and binding rules(see the chaos caused by ValueTuple and HttpClient). On top of that you end up in situations where referencing a random 3rd party library has now hoisted your blessed, well tested shared framework into your application’s bin folder (see .NET Core 1.x)