Live data from Hacker News

.NET Standard 2.1

blogs.msdn.microsoft.com

71–80 of 124 posts

Re: .NET Standard 2.1

#71
post #60

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

I need to highlight, that ASP.NET Core never run on .NET Standard. Some parts always have been dual-compiled for netcoreapp2.0 and net46(?).

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

Re: .NET Standard 2.1

#72

Earlier quoted context omitted.

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

There is still just a lot of stuff you can't do on Core alone. It's fine, I guess, if you are doing fairly vanilla web server development, although the last time I tried it was not the easiest to run .NET Core on Azure. Probably the story is better there now than it was. Microsoft also has the entire silent iceberg of enterprise development that is going to be slogging along with .Net framework applications for years…

The .NET Standard 2.0 push moved a vast amount of code to being compatible on .NET Core alone. The "desktop app packs" for .NET Core 3.0 to run WinForms and WPF closes the gap a lot further.

(.NET Core on Azure seems pretty easy to me. Even from early beta days of .NET Core, but there are certainly even more Azure tools for it today than then, including some really good .NET Core on Docker support from what I hear.)

Yes, enterprises will always be slogging along with ancient solutions so long as "if it isn't broke, don't fix it" aligns with the bottom line. Arguably that seems exactly why .NET Framework might not support .NET Standard 2.1+, because Microsoft doesn't want to accidentally break ancient enterprises if they can avoid it.

Re: .NET Standard 2.1

#73
post #5

Earlier quoted context omitted.

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

At least some convergence is happening: 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/...

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

Re: .NET Standard 2.1

#74

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

Unlikely. [0]

> > Are there plans to support .NET Standard 2.1 in a future version of .NET Framework, or will 2.1 and beyond be .NET Core only?

> Never say never, but given that .NET Standard is accumulative, I don't think it's very likely as the risk argument that applies to .NET Standard 2.1 will always apply to future versions too. And a side-by-side release of .NET Framework is extremely unlikley.

[0]: https://twitter.com/terrajobst/status/1059517534049726464

Re: .NET Standard 2.1

#75
post #58

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

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

Re: .NET Standard 2.1

#76
post #42
post #34

Earlier quoted context omitted.

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

Mono (5.0) and Xamarin (4.5) implement .NET Standard 2.0.

Re: .NET Standard 2.1

#77
post #58

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

We live in a world where Cobol mainframes are still around and in use. Microsoft can not depreciate ten year old technologies when the vast majority of their clientele in this sector are enterprises.

Re: .NET Standard 2.1

#78
post #25

Earlier quoted context omitted.

I highly doubt it. As far as I know WPF is way too entangled with Windows.

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.

The "desktop app packs" for WPF and WinForms Microsoft has made very clear that they will not support anything other than Windows. (They also won't directly be a part of .NET Core according to diagrams, but packages installed on top of it.) It's also unclear if they can be open sourced (they probably cannot be), and if they can't be open sourced it is unlikely a community-led effort could easily work on making them cross-platform.

Re: .NET Standard 2.1

#79
post #60

Earlier quoted context omitted.

I need to highlight, that ASP.NET Core never run on .NET Standard. Some parts always have been dual-compiled for netcoreapp2.0 and net46(?).

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

I believe that ASP.NET Core should be able to move to .NET Standard 2.1 (Span 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.

Re: .NET Standard 2.1

#80

Earlier quoted context omitted.

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

Microsoft here sounds extremely hesitant to ever do the ".NET Framework 5.0" release that would break the .NET Framework world necessary to push a new CLR Runtime out. .NET Framework 3.x and .NET 4.x have all still been using the CLR 2.0 (for the most part), and the risk at upgrading the CLR is far greater than the .NET Framework 1.0 to .NET Framework 2.0 era. (Certainly the "reward" of the new mostly performance-ori…

> Microsoft here sounds extremely hesitant to ever do the ".NET Framework 5.0" release that would break the .NET Framework world necessary to push a new CLR Runtime out.

Yeah, I think the question is "will Framework be the slow moving, but 'living' component you target for long-term, but perhaps not eternal, stability on Windows platforms or will it be a legacy component that Windows is burdened with only for backward compatibility with older apps".

I think Microsoft has sent signals out which point in each of those directions, but not yet converged clearly on one or the other.

Post reply on HN