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

Introducing .NET Standard

blogs.msdn.microsoft.com

Post reply on HN
Print view View original

121–130 of 154 posts

Re: Introducing .NET Standard

#121

Post by terrajobst »

Someone wrote: post #113
dragonwriter wrote: post #112

Earlier quoted context omitted.

> So, do we have ".NET Standard" now and ".NET Standard 2.0" in the future? There are three key versions (and several others; they have 1.0 through 1.6 and 2.0) of .NET Standard referenced; the key versions are 1.5 (supported by .NET Framework 4.6.2 and later and .NET Core 1.0 and later), 1.6 (supported by .NET Framework vNext and later and .NET Core 1.0 and later), and 2.0 (supported by .NET Framework 4.6.1 and late…

So, in a blog post titled "Introducing .NET Standard", it turns out .NET Standard already has 8 different versions? Also, rereading the article, I notice "When we shipped .NET Core 1.0, we also introduced .NET Standard." This text really could do with a good editor.

That's actually a fair point. I probably should have used a different wording.

Re: Introducing .NET Standard

#122

Post by dragonwriter »

maxxxxx wrote: post #118
ihsw wrote: post #35

Earlier quoted context omitted.

.Net Core: cross-platform build tooling, minimal API .Net Standard: cross-platform comprehensive API .Net 4.5: Windows-only build tooling + comprehensive API .Net MVC: Windows-only web framework built on .Net 4+

I am a .Net developer for more than 10 years and I don't know when to use Core or Standard. And why is 4.5 still around when I seem to be able to use Standard? I really wish they would clean up their story. Same for UI. When to use WPF, Winforms or UWP? It's just a mess.

.NET Core is a platform/implementation, like .NET Framework (there are others, as well.) .NET Standard is a "pure" API spec, not an implementation.

Any version of Core supports some version of Standard, as does any version of Framework from 4.5 on. (Framework 4.5 supports Standard 1.1, Framework 4.6.1 supports Standard 1.4 and 2.0, Framework 4.6.2 supports Standard 2.0 and 1.5, Framework vNext will support Standard 1.6 and 2.0, Core 1.0 supports Standard 1.6, Core vNext will support Standard 1.6 and 2.0, etc.)

Standard 2.0 will be a big deal, because pretty much all their active platforms will support it as of their next major version, though the earlier versions provide a handier way than has previously existing for addressing what works against the various .NET implementations, which should somewhat simplify cross-platform .NET development for the existing platforms.

Re: Introducing .NET Standard

#123

Post by intrasight »

They left out what I think is the most important info - when will it ship? They listed a lot of libraries that aren't yet in .Net Core, but they say that those will be added to .Net Core to bring it into compliance with .Net Standard.

Re: Introducing .NET Standard

#124

Post by mellinoe »

bmurphy1976 wrote: post #77
mellinoe wrote: post #58

Earlier quoted context omitted.

> What I want to know is, will the sync (not async/await) methods be available on Linux on .NET Core? Yes, they most likely will be. If you search through the reference assembly interfaces listed here, you should be able to tell whether the functionality you want will be available. https://github.com/dotnet/standard/tree/master/netstandard/r... For things like legacy synchronous or Begin/End async methods, we are mor…

I don't see anything for WebRequest in the referenced repository, but thanks for responding. I'm more hopeful than I've been since we found out .NET Core was async/await only. Migrating to async/await is very close to a complete rewrite for our codebase. We're not interested in it because it's such a big undertaking, and if we're forced to we might as well consider options other than .NET. My preference would of cour…

If you look at this file, you should find the definitions for WebRequest and subclasses. It looks like the synchronous overloads you are looking for are there, but I'm not sure exactly which ones you want. Regardless, they should be there and if they aren't, it's most likely an accidental omission.

https://github.com/dotnet/standard/blob/master/netstandard/r...

I think that GitHub is either having trouble with how large some of these files are, or just hasn't indexed them yet, since they aren't showing up in the repo search.

Re: Introducing .NET Standard

#125

Post by cheez »

jug wrote: post #69
Analemma_ wrote: post #16

I understand that Microsoft has to clean up a lot of legacy baggage around this ecosystem, and it does look like the way forward is much clearer and nicer, but man, was there any way this could've been done without another ".NET "? I'm still figuring out .NET Core/4.5/Framework and all the ASP naming zaniness... and I'm a .NET developer! I do trust Microsoft that this is really, truly the last time this will have to…

I know right... I'm also a .NET developer and I wonder in particular how this new move will relate to .NET Framework. I understand that .NET Core is sort of a subset of it, a new "fresh start" with refactoring done as well as platform-specific code cut in order to be able to support multiple platforms. And that .NET Standard covers .NET Core and .NET Framework as an umbrella. However, where is Microsoft's focus now?…

Windows .NET developers won't need to change what they do. If they want to make portable .NET code (between Linux/Mac and Windows) then they need to get familiar with .NET core.

This is purely about growing market share (and they have my mind, over Java anyway).

Re: Introducing .NET Standard

#126

Post by hermitdev »

btown wrote: post #117
pweissbrod wrote: post #85

Earlier quoted context omitted.

The problem with that is, I feel like by adopting .NET I am the one being fired at by Microsoft

Realistically, you are. There's a bit of lock-in that occurs here: you've spent X% of your career learning the ____ stack, and there's a huge opportunity cost to switching stacks... so ____'s incentives are aligned to make sure that that X% stays X% over time, that you're learning new ____ stuff, rather than their tech stagnating and you being able to use your now-free learning time to learn a competitor's stack. I d…

I know I'm going to be reiterating/rephrasing what you've said, but it's true for any closed stack. Especially Java. At least with C# (maybe not .Net as a whole), at least the language is an ECMA spec (ok, not all versions of C#, but several of them): http://www.ecma-international.org/publications/standards/Ecm...

I appreciate that MS is working to find a common set of libraries. Eventually this refactoring hopefully leads us to the point where we can all use an open-source common set of libraries and then just add on the Windows, Linux, Android or OSX specific parts.

I like the direction MS is heading, in general, with Windows 10, even if there are certain things I don't like. I like that I can run python under WSL because it has a better CLI experience (in my opinion) than the native windows Python build. I also like they are open-sourcing key technologies.

I just wish they would do better about naming so to reduce confusion. I'm confused just looking at the tables of which versions support which versions of the Standard. In the one chart, in .NET Framework 4.6.1 supports standard 1.4. 4.6.2 supports 1.5, vNext supports 1.6. Then also 4.6.1 supports standard 2.0. So, .NET Framework 4.6.1 supports Standard 1.4 and 2.0, but 1.5 and 1.6 support different (presumably incompatible) standards? The way the table reads it's 2 steps forward, 1 step back.

Re: Introducing .NET Standard

#127

Post by Locke1689 »

tracker1 wrote: post #101
dsp1234 wrote: post #98

Earlier quoted context omitted.

In Visual Studio for the same thing you have to use the clunky "Watches" feature. VS has the 'immediate window' which allows you to execute (almost) any statement within the context of the local scope, including intellisense and autocomplete.

Caveat to the use of lambdas... Where, ironically the last time I used .Net was what I needed to inspect the most were subsets of collections or the results of other queries... I always used the function methods for linq over the language extension.

Lambdas are supported in the debugger as of Visual Studio 2015 :)

Re: Introducing .NET Standard

#128

Post by watermoose »

btown wrote: post #117
pweissbrod wrote: post #85

Earlier quoted context omitted.

The problem with that is, I feel like by adopting .NET I am the one being fired at by Microsoft

Realistically, you are. There's a bit of lock-in that occurs here: you've spent X% of your career learning the ____ stack, and there's a huge opportunity cost to switching stacks... so ____'s incentives are aligned to make sure that that X% stays X% over time, that you're learning new ____ stuff, rather than their tech stagnating and you being able to use your now-free learning time to learn a competitor's stack. I d…

Google didn't intentionally change the world in Angular 2 to make sure that developers were learning new Angular 2 stuff vs. something else. If they wanted to do that, they were too late, because a lot of people had moved to React already.

Angular 2 is so different because they were trying to fix all of the problems with Angular 1. In fact, Angular 2 didn't even settle on how to do that after starting early releases of Angular 2. But, that wasn't some secret conspiracy to get people to use it. If anything, a lot of people that were sold on Angular 1 are slower to migrate, but that's what they get for trying to do things right.

Re: Introducing .NET Standard

#129

Post by nightski »

btown wrote: post #117
pweissbrod wrote: post #85

Earlier quoted context omitted.

The problem with that is, I feel like by adopting .NET I am the one being fired at by Microsoft

Realistically, you are. There's a bit of lock-in that occurs here: you've spent X% of your career learning the ____ stack, and there's a huge opportunity cost to switching stacks... so ____'s incentives are aligned to make sure that that X% stays X% over time, that you're learning new ____ stuff, rather than their tech stagnating and you being able to use your now-free learning time to learn a competitor's stack. I d…

Uh, .NET Standard adheres to the APIs in the .NET Framework. It's the same APIs you have been using for many years and that is the entire point of it all. .NET Core initially used a subset that was too painful to port to by a lot of developers so now they are expanding that subset closer to the .NET Framework.

Re: Introducing .NET Standard

#130

Post by [deleted] »

btown wrote: post #117
pweissbrod wrote: post #85

Earlier quoted context omitted.

The problem with that is, I feel like by adopting .NET I am the one being fired at by Microsoft

Realistically, you are. There's a bit of lock-in that occurs here: you've spent X% of your career learning the ____ stack, and there's a huge opportunity cost to switching stacks... so ____'s incentives are aligned to make sure that that X% stays X% over time, that you're learning new ____ stuff, rather than their tech stagnating and you being able to use your now-free learning time to learn a competitor's stack. I d…

[deleted]
Post reply on HN