13 ms·
.NET Standard 2.1
- kodablah 8y ago> Given many of the API additions in .NET Standard 2.1 require runtime changes in order to be meaningful, .NET Framework 4.8 will remain on .NET Standard 2.0 rather than implement .NET Standard 2.1. .NET Core 3.0 as well as upcoming versions of Xamarin, Mono, and Unity will be updated to implement .NET Standard 2.1. At some point, is it reasonable to expect Xamarin, Mono, Unity, and .NET Core to all really be backed by .NET Core? And if/when so, is there any difference between .NET Standard and .NET Core since, after .NET Framework has been essentially maintenance-mode'd, there will be only one .NET Standard implementation? Similar question, besides just having multiple implementations, what benefit is there to having both Mono and .NET Core separate (at least for the .NET Standard impl part)?
- nikofeyn 8y ago.net standard and .net core and two separate things. the former is an api/library specification and the latter is an implementation of that specification. mono and .net framework are also implementations. https://docs.microsoft.com/en-us/dotnet/standard/net-standard https://docs.microsoft.com/en-us/dotnet/standard/net-standar... https://msdn.microsoft.com/en-us/magazine/mt842506.aspx https://msdn.microsoft.com/en-us/magazine/mt842506.aspx
- kodablah 8y agoI understand that, but I am asking if the implementation ends up becoming the only implementation of a specification, is there a meaningful difference between the two? I would expect Mono to use more of .NET Core (or if not, curious why not hence my last question), and .NET framework is no longer an implementation of current and future .NET standard specifications (hence the part I quoted).
- nikofeyn 8y agooh, i see what you mean now. from my understanding, .net core 3.0 will start to make .net core the primary choice of development for new projects on windows since it will include the uwp, wpf, and winforms desktop packs. but if you still need cross-platform ui and graphics, mono is still the only choice. so it does seem that microsoft is converging on trying to "get rid of", so to speak, .net framework and mono, but it seems there's still a ways to go. even a newish project in the wilderness labs meadow board used mono and not .net core for their project. i am sure it's because they started a while ago and there were technical reasons. .net core lacked features mono had for a while (and maybe still does, not for sure of the current status). moving existing projects like it, unity, and xamarin from mono to .net core is probably a huge undertaking. in terms of naming, i think it makes sense to keep the distinction between .net standard and .net core, even if .net core slowly heads towards becoming the de facto implementation. i doubt .net framework and mono ever really go away anyway, so the distinction is still needed.
- oaiey 8y agoMono and .NET Core will never merge. But it is not a black and white thingy. .NET Core has a sub project named corefx (Base Class Library), which acts as a master for most of the class library of Mono nowadays. However, the runtime below (mono or coreclr for .NET) are different animals. Mono is highly optimized on portable code (it runs in many more places than .NET Core) while .NET Core is tuned for performance. Unity is based on Mono but also has yet another different runtime (it basically compiles the code first in C++ and then with C++ backends to the target architecture). Expect here the same as for Mono. It is specialized and will stay specialized.
- kodablah 8y agoThat makes sense with regards to the runtimes and non-spec'd libs. But I was under the impression .NET Standard was essentially the class library spec and if .NET Core is/becomes the only impl of that class library spec it would seem strange to separate the spec from the impl when only one of each exists built by the same blessed implementer. I can definitely understand different compilers, AOT/JIT engines, GCs, etc. Even with minor .NET Standard impl differences in Mono, if they are so minor that they only augment .NET Core, it comes off as an optimization rather than a separate implementation. If the class library impl differences remain major, I would wonder why as surely, even when optimizing for portability vs performance, there is a lot of potential reuse.
- oaiey 8y agoConsider e.g. the cryptography support in the .NET Standard. On Linux it is based on OpenSSL (AFAIR), on Windows based on the crypto library there, on MacOS on another one, on Android another one and let us not speak of iOS. All of them follow on the surface the same API spec. But behind the scenes all .NET implementations have different strategies to deal with. And for good reasons. In this cases you need a standard but not a shared implementation.
- kodablah 8y agoI don't think deferring by platform preference is enough of a reason to separate the standard from the abstracting implementation. Most languages, with or without a "standard" and multiple implementations, defer to the platforms' preferred ways of, say, obtaining cryptographically random numbers.
- Someone1234 8y agoLet me just check if I finally understand this: - .Net Framework: The Windows Specific (and nearly deprecated) branch - .Net Core: The replacement for Framework and cross platform branch (but with Windows specific libraries) - .Net Standard: A way to write something that runs on both .Net Framework and Core?
- RussianCow 8y agoTo clarify: My understanding is that .NET Standard is a specification for a set of .NET APIs that all implementations support, rather than a concrete library or something like that. So if you target .NET Standard with your application, it should be able to run on any .NET implementation. Otherwise, yes, that sounds correct.
- sebazzz 8y agoIt is just an API set you target. You should see it as NodeJS vs Web Browser. They both support a common API set defined in ECMAScript 6 (for instance) which contains Date, Intl.DateFormat, Symbol.iterator, etc. Note that executables cannot be compiled to .NET Standard, because they are self-bootstrapping so they must target one or the other (or both).
- gulbanana 8y agothat was the primary purpose before, but since .NET Framework will no longer be implementing new .NET Standard versions, it's now more like a way to write something that runs on both .NET Core and on Xamarin platforms
- dragonwriter 8y ago> that was the primary purpose before, but since .NET Framework will no longer be implementing new .NET Standard versions .NET Framework 4.8 won't implement .NET Standard 2.1 doesn't mean .NET Framework won't implement new .NET Standard versions. .NET Framework has been announced previously to be slower-movinh and lower-risk than Core, so it's not surprising that it will take longer for it to support new versions of .NET Standard. That the next Framework release won't incorporate the newest Standard doesn't mean Framework won't advance it's Standard support going forward.
- Nelkins 8y agoAnybody got any updates on the state of Mono/.NET Core convergence? I actually don't care very much if they're actually the same code base, but I'd like to be able to use the dotnet CLI for everything. Xamarin project templates in the new SDK format are also on my wishlist.
- BonesJustice 8y agoAre .NET Core and Mono converging? I would have thought that they'd remain separate while both implementing .NET Standard, and becoming interchangeable as .NET Standard implementations.
- Nelkins 8y agoAt least some convergence is happening: https://www.mono-project.com/news/2016/11/29/mono-code-sharing/ https://www.mono-project.com/news/2016/11/29/mono-code-shari... And here's a more recent update: https://www.mono-project.com/docs/about-mono/releases/5.0.0/#corefx--reference-source-adoption https://www.mono-project.com/docs/about-mono/releases/5.0.0/...
- WorldMaker 8y agoAlso, this article on .NET Standard 2.1 mentions that for new features to be considered for future .NET Standard APIs they expect them to be MIT-compatibly licensed in at least one .NET Standard implementation with option for the other implementations to just use it outright, which indicates convergence as a policy goal.
- martinald 8y agoI think Microsoft is missing a trick by at least making some of MVC5 target .NET standard. It would make it a lot easier to port apps over. Moving from asp.net to asp.net core is a big pain in the arse.
- rpeden 8y agoIt seems like the kind of thing that should be possible - after all, Mono has had System.Web for a long time, and can run both MVC and Web Forms apps. I don't know anyone who has actually done so in production, though. But although it's possible, I imagine there are lots of reasons why MS, or certain teams at MS, don't want it to happen. We'll see, though. I didn't expect them to make the decision to add WPF and WinForms support to .NET Core, but they did.
- stevecalifornia 8y agoSuggested naming standard: - .Net API Specification - (now known as .Net Standard) - .Net Windows - (now known as .Net Framework) - .Net Cross Platform - (now known as .Net Core)
- sebazzz 8y agoI don't think Microsoft is going to rename .NET Framework, that would already break too much for too little benefit. .NET Core would simply not be renamed because it is too well known. Regarding ".NET Standard", I agree, it is an API specification but to prevent confusion you should think (for now) of it as "The .NET Standard [API set]".
- paulddraper 8y agoYou're right of course, but it's a crying shame that it's so unobvious what things are.
- blinkingled 8y ago.NET XP sounds better for .Net Core :)
- ctrl-j 8y agoFor Windows XP?
- blinkingled 8y agoSince nobody uses Windows XP anymore that should not be so confusing.
- legulere 8y agoThere’s already universal windows platform, which is basically windows 10 only.
- benaadams 8y ago
- polskibus 8y agoIt's a pity 2.1 will not be implemented by netfx 4.8. I wonder if there will ever be E netfx with netstandard 2.1. Sadly things are not looking good for standardization - on one hand we have new netstandard without netfx and on the other aspnet.core without netstandard (https://github.com/aspnet/AspNetCore/issues/3753 https://github.com/aspnet/AspNetCore/issues/3753).
- merb 8y agoI think it's more a pity that .net core 3.x still can't run ALL the things. i.e. if .net core would run anything that could've run on .net framework/mono whatever by just retargeting to .net core 3.x and even dlls from .net 4.7 could be run on core 3.x than nobody would complain and people would love it since, it would reduce the pain of that many runtimes.
- daeken 8y agoThis is basically where they're headed. .NET Core can now be used for UWP stuff, for instance. It seems to me that they're trying to prevent a situation where people write a bunch of Windows-specific Core code though.
- merb 8y agowell the problem is that they only add some stuff. currently a lot of problems are because of "legacy" web apps, that need to integrate with new ones. i.e. webforms, mvc4, etc...
- WorldMaker 8y agoThe interesting thing to note is that the core runtime in netfx hasn't changed in a long while (.NET Framework 3.x and .NET Framework 4.x are still essentially CLR 2), and it sounds like after what Microsoft learned from the CLR 1 -> CLR 2 (.NET 1.0 -> .NET 2.0) update they never want to do that again if they can avoid it. CLR 1 to CLR 2 had a very good reason to do that (generics); .NET Standard 2.1 has a lot of little reasons, but no good, big reason to break the .NET Framework world with a runtime upgrade. (Also, it looks like ASP.NET Core still should be considered .NET Standard 2.1 compatible, but yes the "upgrade" to .NET Standard 2.1 is fascinating because it loses compatibility with netfx.)
- twblalock 8y agoI thought the Java framework nomenclature was bad, but .Net is way more confusing.
- int0x80 8y agoI was thinking about this... but I'm not so sure :) JRE, JDK, Java EE, Java SE, Beans, Enterprise Beans, Managed Beans, JEE APIs vs Implementations etc, containers, app containers, app servers. 'Enterprise' has to be the worst prefix/name ever for an API or technology. It is a tough contest.
- maxxxxx 8y agoI do mainly desktop dev but reading that Core is now the platform with rapid improvements I wonder if it's possible to write WPF or UWP apps with .NET Core or Standard. Does anyone know?
- michaelwda 8y agoThis is coming in .NET Core 3. Slated for Q1 2019 AFAIK. https://blogs.msdn.microsoft.com/dotnet/2018/05/07/net-core-3-and-support-for-windows-desktop-applications/ https://blogs.msdn.microsoft.com/dotnet/2018/05/07/net-core-...
- maxxxxx 8y agoVery good. For a moment I was worried that desktop development would stay on Framework which from the article seems to slowly being pushed into maintenance mode.
- qwerty456127 8y agoIf WPF is coming in .NET Core, does this mean we are going to be able to run WPF apps on Linux and Mac?
- maxxxxx 8y agoI highly doubt it. As far as I know WPF is way too entangled with Windows.
- qwerty456127 8y agoBut isn't .Net Core meant to be cross-platform?
- SemiNormal 8y agoIt is. The WPF library is just a separate package that includes a lot of Windows API calls to allow .NET Core to talk to WPF.
- c-smile 8y agoSo they added Span<T> as a big thing ... > (Span<T> is) at the heart of most performance-related improvements in .NET Core 2.1. Since it allows managing buffers in a more efficient way, it can help in reducing allocations and copying. We consider Span to be a very fundamental type as it requires runtime and compiler support in order to be fully leveraged. Small struct that is declared as public readonly ref struct Span<T> { private readonly ref T _pointer; private readonly int _length; ... } which is exactly what I am using in Sciter (https://sciter.com https://sciter.com) for 10+ years: template <typename T> struct slice { const T* start; unsigned int length; ... } https://github.com/c-smile/sciter-sdk/blob/master/include/aux-slice.h#L48 https://github.com/c-smile/sciter-sdk/blob/master/include/au... Such small thing definitely speed ups many areas and surprisingly quite a lot, parsing in particular. Nothing new under the Sun, eh?
- nightski 8y agoDoes your template work with memory managed by a GC and provide all the memory safety guarantees that .NET does? If so, does it work seamlessly across the stack & the heap for both managed memory and unmanaged memory at the same time? I get it, similar concepts - but let's not dismiss the value in this addition.
- c-smile 8y agoNo, this is pure C++ (non-managed) thing. It is used strictly in read-only places. It makes absolutely no sense to use things like std::string (and allocate it each time) when you need to pass string or fragment of string or array to consumers. For write-only access I also have target<T> that safely wraps all memcpy, memmove, strcpy[_s] cases.
- misnome 8y agoI didn’t read the poster as dismissing it (or claiming to have outright invented the concept) - rather pointing out that good implementations naturally keep re-arising.
- 8y ago
- hi41 8y agoI thought we already have .NET 4. I don't understand.
- LandR 8y ago.Net framework is upto 4.7 .net standard is now 2.1 .net core is 2.1
- hi41 8y agoThank for clarifying all the "synonyms" associated with .NET. I did not know there were three different things: framework, core and standard. Are there others I am missing?
- WorldMaker 8y agoMono (5.0) and Xamarin (4.5) implement .NET Standard 2.0.
- SemiNormal 8y ago".NET Standard" is the specification that defines the available features. .NET Framework 4.7 (windows) and .NET Core 2.1 (cross-platform) both implement .NET Standard 2.0, meaning they have a shared feature set.
- SimonPStevens 8y agoEverytime I start to think Microsoft is heading in the right direction they go and blow it all away again. This week we've already had a new asp.net core which drops support for .net standard and only supports .net core. And now, a new version of .net standard that .net fx isn't going to support. We are right back at the mess of portable class libraries with all their different supported profiles. It means app devs are constantly dealing with problems like "is this library I want to use, supported by all the targets my app needs to run on", and library devs have a mess of different frameworks and combinations to support, so inevitability drop a few of them unless they are a big project with lots of manpower.
- oaiey 8y agoI need to highlight, that ASP.NET Core never run on .NET Standard. Some parts always have been dual-compiled for netcoreapp2.0 and net46(?).
- SimonPStevens 8y agoAh, my mistake, I didn't know that. Kind of actually enforces my point of the ecosystem being a mess though and the only realistic thing to do is compile for multiple targets.
- WorldMaker 8y agoI believe that ASP.NET Core should be able to move to .NET Standard 2.1 (Span<T> is the big reason they decided they needed to drop .NET Framework support). They dropped .NET Framework, but there's still a case that they can support .NET Standard here, for what that is worth.
- oaiey 8y agoRegards Portable Profile: I think the case is different. .NET Framework will just no longer evolve. It will always stay on .NET Standard 2.0. .NET Standard is not a intersection. It is a small bubble being in a bigger bubble. And the biggest bubble is the latest. The reason Miguel and the Unity folks are so important in this process, is the fact that they have to agree to participate in the latest and biggest version of the Standard.
- oaiey 8y agoI think they prepare already a while the shift to .NET Core as the primary .NET platform (also on Windows). - .NET Core will soon run all three UI technologies of modern Windows UWP, WinForms and WPF (.NET Core 3). - The Windows Compatability Pack for .NET Core shifted some popular .NET Framework libraries to .NET Core (some only on Windows). There are one thing, Microsoft is really bad with: Telling the world that something is deprecated. There is a set of technologies in the .NET Framework which have no future: AppDomains, WCF, Code Access Security, Workflow Foundation, Cardspace, ... (just to name a few). They are all already dead for some years, but no one tells. They are supported in the .NET Framework but no progress happens. And .NET Core will never see them.
- cptskippy 8y ago> Microsoft is really bad with: Telling the world that something is deprecated. There is a set of technologies in the .NET Framework which have no future: AppDomains, WCF, Code Access Security, Workflow Foundation, Cardspace, ... (just to name a few). There's no reason to deprecate a mature product if there's need for it, it has sufficient test coverage, and there's low/no maintenance. There is however a risk involved with deprecating them that users will migrate to another technology stack entirely. WCF is one of those technologies that was deployed heavily in Enterprise and is deeply ingrained in applications and systems going on a decade old. WFC has better support for SOAP than anything I've seen in the open source world and with a minor configuration tweak it can simultaneously support JSON from the same endpoint. Workflow Foundation is in a similar state to WCF, though I wouldn't shed a tear if it vanished off the face of the planet.
- oaiey 8y agoI agree. With everything. However, a not evolving platform is a dead platform. New code should not target this platform. Even for Enterprise environments it not a joy to see the world evolve while you are stuck with a toolset a decade old. It is already now painful to see the difference in tooling between Core and Framework.
- skrowl 8y agoI agree. Don't deprecate just to clean house. Only deprecate when you have a mature / table replacement.
- hnbroseph 8y agoi really wish they would say "the .net standard" rather than just ".net standard". missing that prefixed article is confusing for someone not in the ecosystem (or me at least). even better would be "specification" rather than "standard", the later being a word frequently used to indicate a particular version of some thing.
- terrajobst 8y agoTotally fair. The original name was ".NET Standard Library" but we were too lazy so we shortened it to just ".NET Standard", which then ended up becoming the product name.