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

101–110 of 154 posts

Re: Introducing .NET Standard

#101

Post by tracker1 »

dsp1234 wrote: post #98
oblio wrote: post #97

Earlier quoted context omitted.

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.

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.

Re: Introducing .NET Standard

#102

Post by tracker1 »

drawkbox wrote: post #39
bopcrane wrote: post #6

Earlier quoted context omitted.

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

They will, because ultimately their new OS for developers is Azure. They do push you towards that but it is actually a good cloud system. Microsoft has moved lock-in further up to the cloud (just like everyone else AWS, Google) and the tools are so nice once visual studio is truly cross platform (not just vs code -- though nice competition to sublime/atom/etc) then a tool lockin.

I can imagine VS Code expanding to cover a lot of the VS use case via plugins though...

Re: Introducing .NET Standard

#103

Post by tracker1 »

dblooman wrote: post #38
kennell wrote: post #10

Earlier quoted context omitted.

They are going in the right direction but i feel like they still have a long way to go before people in the Linux/OSX world start taking C# seriously and we see actual products.

Especially with all the hype around containers, C# is left in the cold. The deployment story would have to be as good on Linux for many to even consider production services

I've been able to use several of the onbuild base images with C# projects.. given they weren't anything huge, but it's been pretty cool. Should only get better.

Re: Introducing .NET Standard

#104

Post by Kipters »

tobltobs wrote: post #83
terrajobst wrote: post #65

Earlier quoted context omitted.

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.

And where does fit UWP into this picture? Or what should I use if I want to develop apps for Window Store (or whatever the current name is for that).

UWP is a native framework based on COM. Windows 10 apps use .NET Core (compatible with .NET Standard 1.4) and can access UWP APIs through bindings

Re: Introducing .NET Standard

#105

Post by dsp1234 »

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…

WebRequest isn't present in .net core (afaik). It's replaced by System.Net.Http.HttpClient

Re: Introducing .NET Standard

#106

Post by crudbug »

terrajobst wrote: post #65
crudbug wrote: 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.

Yes, this was exactly my point.

The elements are present, just that the way naming is done is very confusing. The different distribution/namespaces should have clear goals without any naming confusions.

Re: Introducing .NET Standard

#107

Post by makecheck »

Something about their own diagram bugs me: it’s clear that Xamarin covers a wide variety of targets all by itself so (on the surface) it already seems to have an architecture that handles new APIs well. Shouldn’t the logical course be to extend Xamarin and encourage developers to migrate to that?

Given Xamarin code that works on Macs, iOS and Android, no one would call Microsoft’s layer of peanut butter the API to “rule them all” except Microsoft.

Re: Introducing .NET Standard

#108

Post by terrajobst »

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…

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

.NET Core _already_ implements .NET Standard 1.x. It _will_ implement .NET Standard 2.0.

Re: Introducing .NET Standard

#109

Post by terrajobst »

mintplant wrote: post #93
terrajobst wrote: post #74

Earlier quoted context omitted.

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?

No. Think of UWP as WinRT + .NET Core. While .NET Core is available for Linux, WinRT isn't. Within UWP the UI stack is provided by the WinRT side.

Xamarin has an abstraction layer for UI called Xamarin Forms. This will allow you share UI code across .NET Framework, UWP, iOS, and Android.

Re: Introducing .NET Standard

#110

Post by terrajobst »

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.

While we haven't open sourced WinForms, there is a Mono version of Windows Forms. We've talked with the Mono guys about it and the general consensus was that the WinForms API shape doesn't make it very easy for cross-platform.
Post reply on HN