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

71–80 of 154 posts

Re: Introducing .NET Standard

#71

Post by terrajobst »

pja wrote: post #62
terrajobst wrote: post #53

Earlier quoted context omitted.

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.

Thanks, replaced with the link to my post. I'm clearly not a web guy ;-)

Re: Introducing .NET Standard

#72

Post by em500 »

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…

But Android Studio is basically IntelliJ IDEA, which is not that much younger at 15 years.

Re: Introducing .NET Standard

#73

Post by rch »

douche wrote: post #44
rch wrote: post #18

Earlier quoted context omitted.

Last week I might have agreed with you, but it is really difficult when I'm actually dealing with this mess.

Is the pain because it is ASP.NET MVC, or because you're trying to save an outsourced project? I've done that, and I've done greenfield MVC projects; one of these is much more painful than the other.

For better or worse, I have a broad set of painful experiences from which to draw comparisons: PHP, Java (Swing, Spring, OSGI, RMI, Nuxeo), Fortran 77, Managed C++ circa 2004, "modern" Pearl, and even some remarkably awkward Python.

My chief complaint is that it takes less effort to grab an open compiler and get to work on 20 y.o. Fortran (for instance) than it takes to spin up the whole stack that this relatively trivial MVC app requires[-]. Some years ago I would have had to buy the Lahey Fujitsu Fortran compiler, but those days are over as far as I can tell.

Substantive greenfield projects (any platform) are marvelous by comparison; not even in the same ballpark.

[-] Note that most of the platform pain goes away if you're a fungible MS dev, but then there's a more subtle and insidious pain for you to deal with down the road.

Re: Introducing .NET Standard

#74

Post by terrajobst »

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!

Re: Introducing .NET Standard

#75

Post by mythz »

mmargerum wrote: post #67
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.

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

yeah they're getting rid of project.json but they're merging the multi targetting benefits of project.json back into .csproj

Re: Introducing .NET Standard

#76

Post by mcs_ »

I'm still lost. What should I use and when "to go live"? We are small company with a lot of legacy code that wants to upgrade from 2.0 and 3.5. In 2016. Which .NET should we use ?

Re: Introducing .NET Standard

#77

Post by bmurphy1976 »

mellinoe wrote: post #58
bmurphy1976 wrote: post #21

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, 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 course be to leave things that work as-is and get on with the more important aspects of running our business.

Re: Introducing .NET Standard

#78

Post by mattmanser »

em500 wrote: post #72
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…

But Android Studio is basically IntelliJ IDEA, which is not that much younger at 15 years.

The parent's point was that MS have the institutional memory and expertise that you don't get by simply forking someone else's codebase.

Re: Introducing .NET Standard

#79

Post by yazr »

kierenj wrote: post #41
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+

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 ?

Re: Introducing .NET Standard

#80

Post by mattmanser »

geldan wrote: post #56
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…

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 box, but no, time for some bloody regex foo.

It's better than Firefox + IE, by it's not better than proper IDEs by a long shot. And it's got "designed by a programmer" written all over it, the UX is awful.

Post reply on HN