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

141–150 of 154 posts

Re: Introducing .NET Standard

#141

Post by Dayshine »

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

That's only true if Microsoft continue to develop .NET Framework as well as .NET Core.

If I don't want portable code, I don't get support anymore without learning .NET Core?

Re: Introducing .NET Standard

#142

Post by Dayshine »

jongalloway2 wrote: post #95
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+

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

>but your application code (models, views, controllers, services, etc.) should move from ASP.NET MVC to ASP.NET Core pretty smoothly.

Controllers not so much. That's actually where the biggest changes are for most projects.

Re: Introducing .NET Standard

#143

Post by rpeden »

Dayshine wrote: post #141
cheez wrote: post #125

Earlier quoted context omitted.

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

That's only true if Microsoft continue to develop .NET Framework as well as .NET Core. If I don't want portable code, I don't get support anymore without learning .NET Core?

So far I haven't seen any indication that they plan to stop developing the full .NET Framework. I'm sure some parts of it will stop growing - things like WinForms and WebForms probably aren't going to see a lot of attention in the future, but they're also as close to done as software can be. Large enterprises will be using them for probably the next decade or more, even if they get no features at all.

I look at .NET Standard as a good thing. Even if you don't write portable code now, a whole lot more of what you know as the .NET Framework today will be available to Core as part of the standard should you ever want to write portable code in the future.

I think .NET Standard will eventually make it easier to describe what .NET is. Right now, the .NET Framework is way bigger than what most people think about when they hear the word framework. The .NET Framework is a pretty extensive library, plus Winforms, WPF, WCF, ASP.NET, ADO.NET, Workflow Foundation, and probably others I'm forgetting.

Having a robust stdlib in .NET Standard should simplify things. All .NET environments will have the same standard library, and the .NET Framework to .NET Core comparison will be something like the Java EE to Java comparison. I know that's by no means a perfect one to one comparison, but it'll help make it easier for people to understand the difference between the two main non-mobile .NET distributions.

Re: Introducing .NET Standard

#144

Post by [deleted] »

Delmania wrote: post #50
pjmlp wrote: post #37

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.

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

[deleted]

Re: Introducing .NET Standard

#145

Post by smoothdeveloper »

douche wrote: post #47
arenaninja wrote: post #42

Earlier quoted context omitted.

Here's the other side of the coin, as someone who's worked primarily with npm (JS), composer (PHP), had a taste of cargo (rust) and of course yum, apt-get, etc.: packages are awesome. npm is weird and hellish because people write single-function packages, but that isn't the case in other ecosystems. NuGet provides an easy and familiar way for me to get into it, as opposed to having to absorb the entire ecosystem at o…

Nuget does get a little fun when you are dealing with a solution with multiple library projects that feed into a final executable. So far, I've either had to upgrade all versions of a Nuget package across projects, or spend a lot of time messing around with app/web.config assembly redirects. At least the granularity of Nuget packages is not at npm-level fineness, although it does sort of feel like it is trending in t…

Try paket, will save you a lot of headaches with the redirect stuff

Re: Introducing .NET Standard

#146

Post by xorxornop »

vamsipk wrote: post #48
arenaninja wrote: post #42

Earlier quoted context omitted.

Here's the other side of the coin, as someone who's worked primarily with npm (JS), composer (PHP), had a taste of cargo (rust) and of course yum, apt-get, etc.: packages are awesome. npm is weird and hellish because people write single-function packages, but that isn't the case in other ecosystems. NuGet provides an easy and familiar way for me to get into it, as opposed to having to absorb the entire ecosystem at o…

_packages are awesome. npm is weird and hellish because people write single-function packages, but that isn't the case in other ecosystems_ I have no knowledge of how NuGet works but is there anything in NuGet that is stopping the developers from writing/using single line packages?

Technically, no, but the proliferation of those in the likes of the npm ecosystem is almost entirely due to the shittiness of the JS standard library (such as it is...)

. NET, however, has an excellent stdlib, so in practice you simply do not get packages like this.

Re: Introducing .NET Standard

#147

Post by sjellis »

rch wrote: post #26
MichaelGG wrote: post #13

Earlier quoted context omitted.

Portability work started nearly 2 decades ago. .NET has been multiplatform from the start. Around the first release they even had an "open" source version that ran on BSD, thought not with all the libraries.

I get that you can jump through certain hoops to make cross-platform development possible, but the applications I've seen are 'all-in' with MS (even to the point of inappropriately depending on system services like ftp). Portability simply isn't the norm, and it's disingenuous to claim otherwise.

Yes, please let's not try to revise history. I've seen Microsoft evangelists play games like this, and IMO it's a terrible way to promote your preferred platform. .NET Core will stand on it's own merits, it doesn't gain from inaccurate statements about the past.

Re: Introducing .NET Standard

#148

Post by jmkni »

mythz wrote: post #43

As a library author having to target multiple platforms .NET Standard + project.json is much less painful to support than PCL's - looking forward to when we can drop PCL's and just ship .NET Standard builds.

Looking forward to seeing ServiceStack on .net Core/Standard!

Re: Introducing .NET Standard

#149

Post by jmkni »

terrajobst wrote: post #63
mohdmasd wrote: post #57

I don't understand this bit: "In order to allow .NET Framework 4.6.1 to support .NET Standard 2.0, we had to remove all the APIs from .NET Standard that were introduced in .NET Standard 1.5 and 1.6." Does this mean that STD 2.0 will support .NET 4.6.1 but not 4.6.2 ?

It means that .NET Framework 4.6.1 and all later versions will support .NET Standard 2.0. However, .NET Standard 1.5 & 1.6 will not work on .NET Framework 4.6.1. In other words, we removed the APIs from .NET Standard 2.0 that weren't implemented by .NET Framework 4.6.1.

And some people say this is confusing!

Re: Introducing .NET Standard

#150

Post by MichaelGG »

sjellis wrote: post #147
rch wrote: post #26

Earlier quoted context omitted.

I get that you can jump through certain hoops to make cross-platform development possible, but the applications I've seen are 'all-in' with MS (even to the point of inappropriately depending on system services like ftp). Portability simply isn't the norm, and it's disingenuous to claim otherwise.

Yes, please let's not try to revise history. I've seen Microsoft evangelists play games like this, and IMO it's a terrible way to promote your preferred platform. .NET Core will stand on it's own merits, it doesn't gain from inaccurate statements about the past.

The actual design and standard are designed to be multiplatform. You can see it in a lot APIs, like Environment.NewLine -- not needed if you only target Windows.

MS released Rotor as a proof of concept. It's just an argument over implementations, which were admittedly lacking. And the standard parts are smaller than the whole .net bits MS shipped.

Post reply on HN