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

91–100 of 154 posts

Re: Introducing .NET Standard

#91

Post by alrz »

oblio wrote: post #19
wodencafe wrote: post #17

Nothing about Linux, probably because there is no Linux Consumer Market. Looks like Microsoft's EEE strategy is alive and well. This is nothing more than a clever ploy by Microsoft to regain control of C# from the community, becoming the gatekeeper of the new ".NET Standard" library... rather than opening up some of their coveted, proprietary codebase. (Winforms) TL;DR Micro$oft being Micro$oft

> rather than open up some of their coveted, proprietary codebase. (Winforms) What makes you think that open sourcing WinForms would be any good? It's probably tied to Windows to the gills. If anything, they should be doing something else, they should create or even better, support an existing UI toolkit and promote that as their cross platform UI.

UWP is built on Core .NET stack so I suppose it is going to be cross-platform.

Re: Introducing .NET Standard

#92

Post by Someone »

terrajobst wrote: post #61
ep103 wrote: post #24

Earlier quoted context omitted.

I agree 100%. So anyone care to take a stab at it? How does this differ from .Net Core?

.NET Core is a specific .NET platform while .NET Standard is a specification that many .NET platforms, including .NET Core, implement. In other words, .NET Standard is POSIX for .NET.

Small correction: .NET Core _will_ implement it. It has to grow quite a bit to get there.

At least, that's my reading, but they manage to be fairly confusing by mixing present tense and future tense with two different names:

"- .NET Standard is a set of APIs that all .NET platforms have to implement. This unifies the .NET platforms and prevents future fragmentation.

- .NET Standard 2.0 will be implemented by .NET Framework, .NET Core, and Xamarin. For .NET Core, this will add many of the existing APIs that have been requested.

- .NET Standard 2.0 includes a compatibility shim for .NET Framework binaries, significantly increasing the set of libraries that you can reference from your .NET Standard libraries.

- .NET Standard will replace Portable Class Libraries (PCLs) as the tooling story for building multi-platform .NET libraries."

So, do we have ".NET Standard" now and ".NET Standard 2.0" in the future? If so, why don't they say ".NET Standard 2.0 will include a compatibility shim for .NET Framework binaries"?

On the other hand https://github.com/dotnet/standard/blob/master/netstandard/p... seems to indicate the two are synonyms, and version 2.0 is the first version of this framework.

Re: Introducing .NET Standard

#93

Post by mintplant »

terrajobst wrote: post #74
wodencafe wrote: post #17

Nothing about Linux, probably because there is no Linux Consumer Market. Looks like Microsoft's EEE strategy is alive and well. This is nothing more than a clever ploy by Microsoft to regain control of C# from the community, becoming the gatekeeper of the new ".NET Standard" library... rather than opening up some of their coveted, proprietary codebase. (Winforms) TL;DR Micro$oft being Micro$oft

We probably should have mentioned Linux explicitly but it's part of the very first diagram: .NET Core runs on many Linuxes, Xamarin runs on Android's version of Linux. We highly care about making it easy to write code that works cross-plaform, especially on Linux. That's why we created .NET Standard!

I see that UWP is in the .NET Core box. Does this mean that we can or will be able to write GUI apps with UWP that target Linux?

Re: Introducing .NET Standard

#94

Post by david-given »

bopcrane wrote: post #6
arenaninja wrote: post #3

In the last 10 years I wouldn't have bet on C# to be the language to be the most excited about, and yet here we are. Kudos for dealing with fragmentation

I hope 'new Microsoft' continues to embrace open source and cross-platform - I'm very impressed and never would have imagined this direction a decade ago, either

Personally, I think it's all thanks to Oracle. When Microsoft suddenly realised that they were no longer the most hated IT company in the world, the shock was too much for them, and they just stopped trying any more.

...

Seriously, I have, right now, just dropped out of Vim into VSCode to debug a C program, because the VSCode debugger is fantastic. Everything just... works. In fact, I'd drop Vim in a heartbeat in favour of VSCode if only the vim keybindings were better, but right now they're pretty terrible and my fingers get confused. (Mercurial integration would be nice too, but mostly I use hg from the command line so I don't mind.)

I like the new Microsoft.

Re: Introducing .NET Standard

#95

Post by jongalloway2 »

ihsw wrote: post #35
mbesto wrote: post #30

Earlier quoted context omitted.

Does anyone have a breakdown of how .NET Core/4.5/MVC/etc interact, are different, etc?

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

The .NET MVC thing is off.

ASP.NET MVC is a web framework that implements the MVC pattern, as opposed to ASP.NET Web Forms, which was control based. ASP.NET MVC versions 1-5 run on the full .NET framework.

ASP.NET Core includes MVC, and the API has stayed as close asp possible to previous versions of ASP.NET MVC. The lower level bootstrapping / hosting / middleware / config stuff is pretty different (much improved, IMO), but your application code (models, views, controllers, services, etc.) should move from ASP.NET MVC to ASP.NET Core pretty smoothly.

Re: Introducing .NET Standard

#96

Post by Nullabillity »

2bitencryption wrote: post #11
arenaninja wrote: post #3

In the last 10 years I wouldn't have bet on C# to be the language to be the most excited about, and yet here we are. Kudos for dealing with fragmentation

I started using Xamarin to develop an Android app, expecting the Xamarin platform to be some gross in-between which only exists to squeeze just a few more developers onto C#. But, no joke, it's a BETTER experience than Android Studio. I had a much better time using Xamarin Studio (on OS X) and Visual Studio with Xamarin (on Windows) than I ever did with Android Studio. And not just because of the tools: C# provides s…

Did you try Kotlin?

Re: Introducing .NET Standard

#97

Post by oblio »

mattmanser wrote: post #80
geldan wrote: post #56

Earlier quoted context omitted.

Except browser tooling, where they are far ahead of others.

Compared to VS, chrome dev tools are bloody awful. There are some incredibly annoying basic missing features in Chrome dev tools. Like you still can't just hover over a variable, you inexplicably need to highlight it. Functionality that IE dev toolbar had 10 years ago. And don't even get me started on their shitty black boxing solution, something that should be as easy as right clicking on the file you want to black…

Well, on the other hand, while debugging, if I recall correctly, in Eclipse you can select an (almost) arbitrary section of code and evaluate it. In Visual Studio for the same thing you have to use the clunky "Watches" feature. So even VS can improve.

Re: Introducing .NET Standard

#98

Post by dsp1234 »

oblio wrote: post #97
mattmanser wrote: post #80

Earlier quoted context omitted.

Compared to VS, chrome dev tools are bloody awful. There are some incredibly annoying basic missing features in Chrome dev tools. Like you still can't just hover over a variable, you inexplicably need to highlight it. Functionality that IE dev toolbar had 10 years ago. And don't even get me started on their shitty black boxing solution, something that should be as easy as right clicking on the file you want to black…

Well, on the other hand, while debugging, if I recall correctly, in Eclipse you can select an (almost) arbitrary section of code and evaluate it. In Visual Studio for the same thing you have to use the clunky "Watches" feature. So even VS can improve.

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.

Re: Introducing .NET Standard

#99

Post by tracker1 »

Someone wrote: post #92
terrajobst wrote: post #61

Earlier quoted context omitted.

.NET Core is a specific .NET platform while .NET Standard is a specification that many .NET platforms, including .NET Core, implement. In other words, .NET Standard is POSIX for .NET.

Small correction: .NET Core _will_ implement it. It has to grow quite a bit to get there. At least, that's my reading, but they manage to be fairly confusing by mixing present tense and future tense with two different names: "- .NET Standard is a set of APIs that all .NET platforms have to implement. This unifies the .NET platforms and prevents future fragmentation. - .NET Standard 2.0 will be implemented by .NET Fra…

They're considering .Net Framework 4.6.x to be the guideline for Standard 1.x, And that when Core 1.0 hits, it will support .Net Standard 2.0.

My guess is jumping to 2.0 for future implementation base is to avoid conflicts with .Net Core 1.0 (though may exacerbate the issue)

Re: Introducing .NET Standard

#100

Post by pjmlp »

terrajobst wrote: post #53
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 fully share your concerns. I've expressed this problem with a homage to XKCD: https://blogs.msdn.microsoft.com/dotnet/2014/12/04/introduci... Don't think of .NET Standard as another .NET platform. Think of it as the standard that ties them all together. It's similar in spirit to POSIX. It's not another Unix, it's a way to write code that works on multiple Unixes.

I think of POSIX as the actual C runtime.
Post reply on HN