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

81–90 of 124 posts

Re: .NET Standard 2.1

#81

Post by WorldMaker »

oaiey wrote: post #55
WorldMaker wrote: post #51

Earlier quoted context omitted.

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

ASP.NET Core is not .NET Standard based. Most of its libraries are, but the core runtime is bound to a platform like .NET Core (and earlier the .NET Framework). It was never running on a pure .NET Standard interface.

One of the biggest reasons for that seems to be Span, so it seems possible that ASP.NET Core can move toward .NET Standard 2.1, since it includes Span. Certainly it isn't guaranteed, but it seems plausible. (Not that it would help much in the case that .NET Framework doesn't seem to be capable of .NET Standard 2.1.)

Re: .NET Standard 2.1

#82

Post by pjmlp »

mbesto wrote: post #53
stevecalifornia wrote: post #10

Suggested 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)

Knowing the differences here is pretty serious for my day-to-day work. Does anyone have a guide/breakdown/etc that I can refer to that explains all of the versions of .NET? The documentation from Microsoft itself is atrocious. Does it exist somewhere?

Not a breakdown, but here goes.

https://docs.microsoft.com/en-us/dotnet/framework/whats-new/

Only goes down to 4.5, as older versions are already EOL.

The archived MSDN docs do have the older versions in case you are interested.

Which runtimes implement which versions of .NET Standard:

https://docs.microsoft.com/en-us/dotnet/standard/net-standar...

Re: .NET Standard 2.1

#83

Post by da_chicken »

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

.NET Framework isn't depreciated in the same sense that Mozilla Suite wasn't depreciated while Phoenix/Firebird/Firefox was being developed. .NET Framework is, at best, on the equivalent of an LTS branch. You'll get bug fixes, but few, if any, new features. Microsoft is clearly making .NET Core the premier framework going forward and .NET Framework is expected to die.

If you ask Microsoft, they'll currently tell you otherwise, but that's because that's a bad idea from a marketing perspective. You don't let your customers know you're going to end of life your product that they used for 15 years until you have absolutely no other choice.

Re: .NET Standard 2.1

#84

Post by zamalek »

hoppelhase wrote: post #61
c-smile wrote: post #48

Earlier quoted context omitted.

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

Well, both implementations do have a strict which has the length as last member. Is there any special reason for it? Something like struct-layout optimization?

You can re-interpret the struct to a pointer (length would simply be truncated). Apart from that there wouldn't be any benefit: the pointer and length would be aligned no matter which position they take (on x86 and amd64 at the very least).

Re: .NET Standard 2.1

#85

Post by pjmlp »

oaiey wrote: post #54
polskibus wrote: post #11

It'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 ).

I think it is fair to say, that we need to realize, that .NET Core runs on all of the platforms which in Microsoft view have future (.NET Core, Xamarin, Unity and UWP). The only platform no one is really interested (from Microsoft perspective) is the .NET Framework. The .NET Framework is, from Microsoft .NET and WIndows Team perspective, a legacy burden which is unable to innovate, change or improve due to the deploy…

The problem is see is not being able to go to .NET Core because of third party dependencies.

And we still have lots of them that until now haven't cared much about .NET Core.

Re: .NET Standard 2.1

#86

Post by pjmlp »

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…

Well, to be fair Modula-3 and Eiffel did it first.

And I bet Sciter is younger than any of them.

Re: .NET Standard 2.1

#87

Post by orra »

hoppelhase wrote: post #61
c-smile wrote: post #48

Earlier quoted context omitted.

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

Well, both implementations do have a strict which has the length as last member. Is there any special reason for it? Something like struct-layout optimization?

I don't think so. My guess would be that it is because a pointer to the struct can be cast to a pointer to T. I /think/ that is defined behaviour.

Re: .NET Standard 2.1

#88

Post by pknopf »

rpeden wrote: post #64
Nelkins wrote: post #23

Earlier quoted context omitted.

Not WPF per se, but if you're looking for something similar check out https://github.com/AvaloniaUI/Avalonia

Xamarin Forms also has WPF, OSX, and GTK renderers, so it might be an option. Based on GitHub activity it looks like they're being worked on fairly actively, too.

You can also use QML with .NET Core.

https://github.com/qmlnet/qmlnet

It is stable, I'm currently using it in production (https://medxchange.com/4klear-all-in-one-camera-recorder/)

PS: I'm the author.

Re: .NET Standard 2.1

#89

Post by qwerty456127 »

WorldMaker wrote: post #78
qwerty456127 wrote: post #27

Earlier quoted context omitted.

But isn't .Net Core meant to be cross-platform?

In general, yes, but a lot of its cross-platform capabilities are community-contributed/community-led, there are still some APIs that don't have cross-platform implementations (because it hasn't been a community priority), but also there are APIs that simply can't work on any platform but Windows (obvious things like Registry access, for instance) and will either no-op or throw clear exceptions on other platforms. Th…

> The "desktop app packs" for WPF and WinForms

WinForms work quite nice on Linux with Mono. Won't they cooperate?

Re: .NET Standard 2.1

#90

Post by maxxxxx »

qwerty456127 wrote: post #89
WorldMaker wrote: post #78

Earlier quoted context omitted.

In general, yes, but a lot of its cross-platform capabilities are community-contributed/community-led, there are still some APIs that don't have cross-platform implementations (because it hasn't been a community priority), but also there are APIs that simply can't work on any platform but Windows (obvious things like Registry access, for instance) and will either no-op or throw clear exceptions on other platforms. Th…

> The "desktop app packs" for WPF and WinForms WinForms work quite nice on Linux with Mono. Won't they cooperate?

I think Mono Winforms is a total rewrite of the Windows Winforms. There is no shared code.
Post reply on HN