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

131–140 of 154 posts

Re: Introducing .NET Standard

#131

Post by nightski »

cheez wrote: post #125
jug wrote: post #69

Earlier quoted context omitted.

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

Actually this makes it easier. It expands the subset of the .NET Framework that .NET Core supports. It's the same APIs we have used forever, just more of which are now available on other platforms (.NET Core, Xamarin)

Re: Introducing .NET Standard

#132

Post by tracker1 »

Locke1689 wrote: post #127
tracker1 wrote: post #101

Earlier quoted context omitted.

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

Thanks.. can you tell I haven't done nearly as much .Net for the past couple years? ;-) Though the .Net core stuff has me relatively excited for the platform again.

Re: Introducing .NET Standard

#133

Post by rodrigokumpera »

yazr wrote: post #79
kierenj wrote: post #41

Earlier quoted context omitted.

Not quite (I think): .NET Standard is an API definition, or rather a versioned set of them. ".NET Framework" (e.g 4.5) "implements" that definition, with some extra features to boot. ".NET Core" also implements it. It's a cut-down (though not very), cross-platform implementation of the .NET Standard. Mono is another implementation of the standard.. cross-platform too, but this time compatible with the actual .NET Fra…

R U saying that (currently) Mono is a superset of Core ? So i am starting with a large and varied Win code base, i will have an easier time porting (as much of it as possible) to Mono rather than Core ?

MS engineer here, I work on mono.

Mono is not a strict superset of .net Core. We follow desktop more closely.

The extra APIs that are part of .net core, and are features on .net standard 1.6 will come to mono as we get the time to implement them.

Re: Introducing .NET Standard

#134

Post by pjmlp »

watermoose wrote: post #128
btown wrote: post #117

Earlier quoted context omitted.

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…

We can also give Android APIs as an example instead of Angular, or the whole IDE and NDK reboot.

Re: Introducing .NET Standard

#135

Post by aandrieiev »

rodrigokumpera wrote: post #133
yazr wrote: post #79

Earlier quoted context omitted.

R U saying that (currently) Mono is a superset of Core ? So i am starting with a large and varied Win code base, i will have an easier time porting (as much of it as possible) to Mono rather than Core ?

MS engineer here, I work on mono. Mono is not a strict superset of .net Core. We follow desktop more closely. The extra APIs that are part of .net core, and are features on .net standard 1.6 will come to mono as we get the time to implement them.

Is mono going to be fully merged into .net _something_ (core? standard?) at some point in the future or it will remain separate?

Re: Introducing .NET Standard

#136

Post by fuck_google »

pjmlp wrote: post #60
Delmania wrote: post #50

Earlier quoted context omitted.

> I still don't understand how Microsoft was able to provide a better debugging and tooling experience for Android, than Google itself for their own OS, although Android Studio 2.2 finally seems to be usable. Visual Studio was first released in 1997, the company has 20 years experience in designing and building tooling. I believe they also have a very firm dogfooding policy, and some very intelligent people work ther…

Surely a few of those PhDs able to draw inverted tree algorithms on the whiteboard should be capable of producing a proper IDE that doesn't hang the computer all the time, an OS simulator and get their mind around how to have an actual working build system for NDK users.

Perhaps they just don't care about such menial matters because everyone knows they are above that.

Re: Introducing .NET Standard

#137

Post by tychuz »

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…

How come? So GetFoo() is replaced by GetFooAsync(), so just mass rename GetFoo() to GetFooAsync().Result and the end result will be the same...

Unlike in JavaScript, async stuff is optional in C#, so block threads to your heart's content with .Result, it will behave like old sync methods...

Re: Introducing .NET Standard

#138

Post by tychuz »

taspeotis wrote: post #116
bmurphy1976 wrote: post #77

Earlier quoted context omitted.

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…

I have been grafting asynchronous support into my codebase by a) writing new code with it and b) using AsyncContext [1] to run asynchronous stuff synchronously. The performance:lines of code ratio you can get with async is quite high. Using ADO.NET you can run mutually exclusive queries in parallel for up-to a 2x speedup (depending on what the queries need to do): using (var connection1 = ...) using (var connection2…

Yes, multithreading is stupidly easy nowadays. I also use Parallel.ForEach and sometimes .AsParallel() - changing "header" of foreach/for cycle is easy peasy and performance gains are instant. :)

Re: Introducing .NET Standard

#139

Post by davidfowl »

ep103 wrote: post #24
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 agree 100%. So anyone care to take a stab at it? How does this differ from .Net Core?

https://gist.github.com/davidfowl/8939f305567e1755412d6dc0b8...
Post reply on HN