.Net Standard 2.1? #682
Comments
|
From @danmosemsft on March 8, 2018 0:0 @ahsonkhan are these in OOB packages? |
|
From @ahsonkhan on March 8, 2018 0:15
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.
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.
Can you help address this, especially if I missed something? |
|
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. |
|
From @Joe4evr on March 8, 2018 7:3
Yes, I've been wondering myself why there are methods in |
|
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. |
|
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.
|
|
@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". |
|
Link to related mono project issue mono/mono#6845 |
|
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. |
|
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 |
|
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. |
|
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. |
|
Same issue for me, but looking for |
|
This issue makes for a very sobering read. I dare say that the new 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 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 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 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. |
|
@fredericDelaporte said:
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 |
|
|
|
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 |
|
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. |
|
@SidShetye see the version proposal at https://github.com/dotnet/designs/pull/29/files?short_path=579bdc1#diff-579bdc17733868e490e711c1245bb183 TL;DR the switchover to |
|
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. |
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? |
|
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. |
|
@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? |
|
@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. |
|
If we rev the standard at the pace of the fastest platform, doesn't that defeat the purpose? |
|
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. |
|
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. |
|
I'm glad I found this discussion because I too was one of the people thinking .NET Standard was the target to use for everything. Now I can see why that can no longer be the case, but I think I understand the reasons behind it a bit better. Whilst I still very much hope the radius of .NET Standard can keep on increasing I don't think that should stop .NET Core from moving on if it needs to, otherwise the team could be pushed behind a very long time. It's a bitter pill for library developers for sure... but essentially it looks like it came to the point where "the free lunch is over" and there are compromises to be made again. Arguably Microsoft could've managed these expectations better but I'm sure a lot of these realizations also came about as work was being done and the team discussed between themselves and the community. Most of us will know the pain of working with legacy stuff to sympathize. The important thing now is knowing whether .NET Standard will keep evolving so people can figure out if they can/should wait for a new rev or if multi-targeting will be the only possible option from here on. |
|
A note about the governance model is up. It states
..and framework already decided against this ref Rich Lander To me this reads that this will not go into the standard before framework is "no longer updated". @nsboard Can you please clearify? |
|
So we’re essentially waiting for full framework to go on extended support (security updates only), which it defacto already is.
If security updates count as updates, we’re waiting for full framework to go EOL, which won’t happen for decades (see vb6). In that case .net standard is dead.
|
|
I'm disappointed that they went with ".NET Standard is the lowest common denominator" instead of ".NET Standard is .NET". I'm not convinced lowest common denominator .NET Standard is of much use. It'll help facilitate the transition from Framework to Core and then that's it. |
If .NET Standard is primarily to bridge OG Framework + Core, and .NET Core 3.0 will support Windows/desktop, then perhaps that's a sign that eventually the library targets should just be |
Yes, that's what I'm thinking. If Standard lags as much as it sounds like it will from reading the governance document then .NET Core becomes de facto the real standard. |
We pretty much went with .NET Standard is .NET approach. Portable Class Libraries (PCLs) were the "lowest common denominator" approach. The difference isn't so much in tooling but in intention. In PCL's case, the platform owners didn't care about portability (some did, but many didn't). We cared about portability so we built a system that maximizes code reuse by given you the biggest possible intersection, which we called profiles. With .NET Standard, we inversed that. We want to be intentional about which APIs should be everywhere while at the same time we try to avoid holding all platform hostage and prevent them from innovating and shipping new APIs just because the APIs weren't standardized yet. We believe this gives us the best of both worlds: platforms are largely independent while we retain a shared standard and vision for all .NET implementations that library authors an rely on. The .NET Standard isn't locked in if a specific .NET platform is no longer advanced. Take, for example, Silverlight or Windows Store (precursor to UWP). They are both done in that we no longer add APIs to them. Whether or not they get updated for security/reliability bug fixes is orthogonal from .NET Standard view point. They just remain on an older version of the standard. |
|
Given that there is PR for .NET Standard vNext (albeit it marked as work-in-progress) I believe this issue can be closed. @jherby2k's original ask was:
You can now track #785.
.NET Standard can only get new members on existing types if we rev the standard itself, which is the plan. And for the upcoming version of the standard we intend to bring all these methods that accept and return |
|
Although it seems like I'm late to the party, I put my 2 cents in. Perhaps the main source of confusion is the poor naming decision made? Span and other classes from System.Memory package are intuitively feeling like something foundational due to "System" namespace and that's why people expect them to be part of .Net Standard. Maybe it's a better idea to name the platform specific things (even those to become part of .Net Standard eventually) differently, e.g. put them in Microsoft.NetCore.* namespace rather than in System.* namespace? |
|
Why do we even need .Net Framework and mono to continue evolving (they could be left behind as legacy just being hotfixed) .Net Core seem to be working so well. I am thinking that because of the way it was engineered where it does not depend on previous versions, allowing it to evolve without breaking previous work, then it should be the main focus of .net for now and the future, and platform specific libraries would be released as individual packs for each platform, that way when new stuff comes to .Net it would not have to be implemented more than once and everyone would know the latest .net core means the latest features, and whatever version my lib is on I could stay on and it would work anywhere cause its .net core ...just thinking out loud |
For the Mono (and related Unity) side CoreCLR is missing some architecture and platform support as it doesn't run on the following which Mono does: Linux (s390x, SPARC, PowerPC, MIPS), Solaris (SPARC, x86-64), IBM AIX, macOS (PowerPC), Wii, FreeBSD, OpenBSD, NetBSD, Android, iPhone, tvOS, watchOS, PlayStation 3, PlayStation 4, XboxOne (Exclusive mode), Webassembly |
The question is then, what purpose? |
The purpose of the standard is to drive convergence. I think what Fowler was concerned about is that if the standard revs very fast you can build libraries that don't run everywhere yet. But given that these point in time issues will always exist, I don't buy this as a counter argument of reving the standard either. That being said, we cannot rev the standard too fast in the sense that we need to take our time to understand if the concepts we're planning on adding can and will likely be supported by all current but also future platforms. Unfortunately this isn't an exact science. |
If so, then the standard should be in the forefront and the discussion should be on what to put in the standard and how to evolve it.
👍 Microsoft have managed to get a lot of developers to use .netstandard as the base for their own libraries, not because of necessity, but to prepare for future alternatives. |
I think they should only be in the standard if they are actually a standard, I'd disagree with experimental features being put in something with a name like standard. Sounds like a great way to start confusing people, especially if those experimental features ever disappear from something that is supposed to be a standard by definition. They just don't mix, IMHO. |
Yes, sorry, bad wording on my part. By 'standard implementation' I was just referring to .Net core etc. namespace Microsoft.NetCore.whatever when experimenting |
|
The standard is about driving convergence but the standard is not about defining & building the features themselves. Any feedback on the actual design of the feature needs to be made in the context of the platform that first introduces them. In other words, the standard is only about adding concepts that already exist in one implementation so that (1) other implementations also gain the feature and (2) developers can write portable code that uses the feature. In other words, we aren't previewing any features with the standard. |
Ah yeah that makes a lot more sense to me now. :) |
|
This model doesn't work for us because it forces us to either make breaking changes after the feature got standardized or live with duplication after standardization. |
That is not a standardisation approach.
You have chosen the model, and duplication, with deprecation policies, is part of such an standardisation model. Or stop calling it a standard. It is just a collection with nice parts from everywhere. |
will be done with .Net 5 which is .net core and old framework is left at version 4.8. |
and others
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
The text was updated successfully, but these errors were encountered: