Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

.NET Standard 2.1

blogs.msdn.microsoft.com

Post reply on HN
Print view View original

41–50 of 124 posts

Re: .NET Standard 2.1

#41

Post by nikofeyn »

kodablah wrote: post #16
nikofeyn wrote: post #9

Earlier quoted context omitted.

.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-standar... https://msdn.microsoft.com/en-us/magazine/mt842506.aspx

I 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).

oh, 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.

Re: .NET Standard 2.1

#42

Post by hi41 »

LandR wrote: post #34
hi41 wrote: post #29

I thought we already have .NET 4. I don't understand.

.Net framework is upto 4.7 .net standard is now 2.1 .net core is 2.1

Thank 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?

Re: .NET Standard 2.1

#43

Post by c-smile »

misnome wrote: post #40
nightski wrote: post #30

Earlier quoted context omitted.

Does 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.

I 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.

Yeah, this concept is quite old.

It reincarnated quite many times: in D language by Walter Bright where arrays are just such slices. Or by Andrei Alexandrescu in its range thing: http://www.informit.com/articles/article.aspx?p=1407357&seqN...

Re: .NET Standard 2.1

#44

Post by hoppelhase »

c-smile wrote: post #26

So they added Span as a big thing ... > (Span 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 { p…

Any special reason why they put the length after the pointer? Or is it just a coincidence?

Re: .NET Standard 2.1

#45

Post by Someone1234 »

taco_emoji wrote: post #31
Someone1234 wrote: post #7

Let 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?

.NET Framework is not anywhere close to deprecated, AFAIK...

I guess it is a matter of perspective and your definition of the word "deprecated". This is the definition I use (from Wikipedia):

> In several fields, deprecation is the discouragement of use of some [..] feature

Microsoft are currently telling people for new projects only use .Net Framework if you have a specific requirement, otherwise use .Net Core. .Net Core is therefore the default choice.

That to me is discouragement which starts to put .Net Framework into the realm of depreciated. Is it deprecated yet? It is not, but it is definitely going in that general direction and you can see it on the distant horizon.

Re: .NET Standard 2.1

#46

Post by oaiey »

kodablah wrote: post #4

> 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…

Mono 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.

Re: .NET Standard 2.1

#47

Post by SimonPStevens »

Everytime 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.

Re: .NET Standard 2.1

#48

Post by c-smile »

hoppelhase wrote: post #44
c-smile wrote: post #26

So they added Span as a big thing ... > (Span 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 { p…

Any special reason why they put the length after the pointer? Or is it just a coincidence?

Question is not clear.

The Slice is just an address of memory chunk combined with the length of that chunk. That's somehow better than "C strings" - that are just pointers and so you need to do some computation if you need to get length of the string. Such C strings have too many drawbacks - in particular strtok function that modifies input string (that shall be read only all times).

Re: .NET Standard 2.1

#49

Post by zerocrates »

dragonwriter wrote: post #36
gulbanana wrote: post #19

Earlier quoted context omitted.

that 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

> 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…

> This means that .NET Core will get new APIs and language features over time that .NET Framework cannot. At Build we showed a demo how the file APIs are faster on .NET Core. If we put those same changes into .NET Framework we could break existing applications, and we don’t want to do that.

The "slower" explanation doesn't really fit with that sentence to me... if Standard 2.1 already has things that Framework "cannot" have, then it seems like "stopped" is more accurate than "slower." I guess technically they only are saying that Core gets things Framework can't, not necessarily the standard, but I'm not sure that's much of a distinction in practice.

Of course it doesn't have to mean that Framework is just frozen but it would seem to make the Standard a bit of a dead letter (I'm not really familiar with how useful it is in terms of Xamarin/Mono/Unity).

Re: .NET Standard 2.1

#50

Post by merb »

daeken wrote: post #33
merb wrote: post #17

Earlier quoted context omitted.

I 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.

This 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.

well 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...
Post reply on HN