Live data from Hacker News

Introducing .NET Standard

blogs.msdn.microsoft.com

61–70 of 154 posts

Re: Introducing .NET Standard

#61
post #24

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?

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

Re: Introducing .NET Standard

#62

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.

:)

As an aside, the content type for that URL is application/octet-stream, so Firefox won’t view the image but insists on downloading it. It needs to be image/png to be viewable in browser I believe.

Re: Introducing .NET Standard

#63

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.

Re: Introducing .NET Standard

#64

I can't really make heads or tails of this, it's still fairly complicated and I'm just not invested enough in it to read everything with a fine toothed comb. What I want to know is, will the sync (not async/await) methods be available on Linux on .NET Core? We've been struggling with that, the move to async/await is a major rewrite of our legacy application codebase and for what we do Mono has been a constant thorn i…

> What I want to know is, will the sync (not async/await) methods be available on Linux on .NET Core?

Yes.

> In an ideal world the old sync APIs would just work and we'd be able to move forward with .NET Core as it stabilizes and get off Mono without a major rewrite.

Yes, being able to move forward with existing code is the primary reason they were added to .NET Standard.

Re: Introducing .NET Standard

#65
post #46

I am not a .NET developer. But, Core / Framework / Standard nomenclature is very confusing. Windows and Universal Windows Platform (UWP) also adds further confusion. They should explicitly define namespaces : 1. XAMARIN namespace as cross platform APIs for .NET ecosystem - iOS, macOS, Android, Linux, may be Web ? 2. UWP/CASCADE ? namespace for Windows 10 systems. 3. WINDOWS namespace for backward compatible .NET Fram…

I can see that being a problem. Let me try to explain:

* We've concrete .NET platforms, such as .NET Framework, .NET Core, and Xamarin. They are the moral equivalent of Linux distributions. * With .NET Standard we now have shared specification that dictates which APIs all these platforms have to implement. That's the moral equivalent of POSIX.

Re: Introducing .NET Standard

#66

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 ?

[deleted]

Re: Introducing .NET Standard

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

Sounds to me like project.json going bye bye

"After looking at our choices, it was apparent that it would be easier to move .NET Core projects to .csproj/MSBuild so all .NET projects use the same tooling and build system."

Re: Introducing .NET Standard

#68

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 ?

> Does this mean that STD 2.0 will support .NET 4.6.1 but not 4.6.2 ?

No, it means that .NET 4.6.1 supports .NET Standard 2.0 but not 1.5 or 1.6; .NET 4.6.2 supports .NET Standard 2.0 and 1.5 but not 1.6, and .NET vNext will support all of 1.5, 1.6, and 2.0.

Re: Introducing .NET Standard

#69

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? Is .NET Core the future? What about .NET Framework 5? Will it happen? What about UWP? .NET Framework include a _ton_ of legacy stuff now. Windows Forms. Heck even WPF can be argued to be in the past, now that UWP is the future? UWP isn't directly interchangeable with WPF even though the technologies are confusingly similar. What about ASP .NET vs ASP .NET Core? What about Entity Framework vs Entity Framework Core? Is Microsoft honestly going to move them ALL forward at a good pace? That sounds like an insane undertaking!

I'm sure they want Windows devs to develop UWP apps for the Windows Store. Still, are they cannibalizing on that platform with this move? Windows Phone essentially doesn't exist. Xbox? Many wouldn't care about universal Windows apps and suffering by having to follow "weakest link support" due to non-existing smartphone platforms. Many devs would hit a MUCH larger target if developing .NET Core and targeting the web for anything UI related.

I wish Microsoft was more clear on this, but maybe the issue here is that they don't know either where they're going since it depends on where the devs are going... This whole .NET ecosystem is becoming extremely large and complex, even when singling out Windows. A whole lot has happened in a short time that it's dazzling.

Re: Introducing .NET Standard

#70

I lead a .NET development team, and I have no plans start using Core any time soon. That's based on my experience testing it out -- just too different, too based on a myriad of nuget packages (which is too much like NPM for me). This confirms my decision. I'm sure it will be nice once it's all sorted out. The money quote for me is below: Since our goal was to represent any .NET platform we had to break it up into sma…

I'm on the opposite side of the coin. I only start up a windows VM when I absolutely have to. Yet, here I am building an ASP.Net Core MVC web app on a mac using nothing but project.json and the command line dot net tool. So far its worked pretty well. I'd still personally use GO but my employee know .net so...
Post reply on HN