Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

.NET Core 3.0 Concludes the .NET Framework API Porting Project

github.com

Post reply on HN
Print view View original

41–50 of 317 posts

Re: .NET Core 3.0 Concludes the .NET Framework API Porting Project

#41

Post by gnud »

jug wrote: post #3

.NET Core 3.0 was major achievement for Microsoft and I like the air surrounding the project and some around it like Visual Studio Code and Windows Subsystem for Linux. The teams working for Windows development are overall on a roll these days and it's both sad and a little mysterious how Windows 10 is still struggling with QA issues, decisions like dismantling their internal testing teams, dual control panels and in…

I love it every time I get the 'old' control panel. It means I know where the switches are, and more importantly, what they do.

The new UIs change with every minor update. Layout, labels and semantics. It's truly horrible. Please don't encourage Microsoft to mess it up even more.

Re: .NET Core 3.0 Concludes the .NET Framework API Porting Project

#42

Post by james_s_tayler »

denisw wrote: post #15
jeswin wrote: post #7

Given that our deployment platform was Linux (for a .Net Core 3.0 project), I was determined to use Linux and VS Code for development. That was a fail; the verbose nature of C# and the Framework APIs make it impossible to be productive without significant help from a full-fledged IDE like Visual Studio. One might think the verbosity can be reduced by clever coding (and adopting a functional style), but that's not so…

If you install the VS Code's C# extension, you should be getting autocomplete and quick fixes such as adding impport statements automatically. https://code.visualstudio.com/docs/languages/csharp

It's still nowhere near the same level of experience that Rider or VS offer.

Re: .NET Core 3.0 Concludes the .NET Framework API Porting Project

#43

Post by pjmlp »

jmkni wrote: post #39
gtsteve wrote: post #32

Earlier quoted context omitted.

If you'd like to develop on Linux, I suggest trying Jetbrains Rider. It's as good as VS in most cases, and better in several. I've used it as my primary IDE for most of this year.

+1 for Rider. It's basically ReSharper.

Including resource usage! As anything on top of InteliJ.

Re: .NET Core 3.0 Concludes the .NET Framework API Porting Project

#44

Post by jmkni »

pjmlp wrote: post #20
mjfisher wrote: post #6

Can anyone closer to the .NET community than I am comment on the wider adoption of .NET core on standard line of business applications? The few places I know that work with .NET are a long way from migrating yet. Are there any similarities with the Python 2/3 port? I imagine language level compatibility makes the transition much easier.

For our customers, we still don't bother with it beyond a couple of toy projects. Most of our customers are doing transitions to .NET Framework 4.7.1 and 4.7.2 from 4.5 and such, .NET Framework 4.8 still isn't a viable option for them, and plenty of in-house, and third party libraries they depend on aren't yet on .NET Core. By .NET 5, they might start moving into Core infrastructure. And for those teams the multi-pla…

Serious question, what makes 4.7.1/4.7.2 viable, but 4.8 not? Major breaking changes?

Re: .NET Core 3.0 Concludes the .NET Framework API Porting Project

#46

Post by jayd16 »

mjfisher wrote: post #6

Can anyone closer to the .NET community than I am comment on the wider adoption of .NET core on standard line of business applications? The few places I know that work with .NET are a long way from migrating yet. Are there any similarities with the Python 2/3 port? I imagine language level compatibility makes the transition much easier.

We're using it for a game server that interfaces with a Unity client. Works damn well. As someone who makes games, that's a standard business application for me, but YMMV.

Re: .NET Core 3.0 Concludes the .NET Framework API Porting Project

#47

Post by ptx »

sytelus wrote: post #26
denisw wrote: post #17

Earlier quoted context omitted.

The crazy high numbers are due to a fairly Microsoft-specific definition of "API" in this context. What they count here is class members; so they ported a class with 15 methods and 3 properties, they'd count this as "18 APIs" (or perhaps 19 - not sure if the class itself counts as an "API" as well). That being said, I'm sure there was indeed an impressive amount of code that had to be ported.

All public members are legitimate APIs. Would you be more happy if every property had get* and set* methods so now it counts as two?

I think the point was that often "an API" means a larger collection of functions, classes, properties, etc. Like the COM API, the DirectX API, the MFC API and so on.

Re: .NET Core 3.0 Concludes the .NET Framework API Porting Project

#48

Post by darklajid »

mjfisher wrote: post #6

Can anyone closer to the .NET community than I am comment on the wider adoption of .NET core on standard line of business applications? The few places I know that work with .NET are a long way from migrating yet. Are there any similarities with the Python 2/3 port? I imagine language level compatibility makes the transition much easier.

I recently switched companies from one .Net shop to (kinda, sorta) another.

The previous one had a big product based on a COM-turned-WCF architecture for years. WCF is dead/not a thing on .Net core.

The one I'm currently looking at just recently (last year-ish?) migrated from idk what to .. a big pile of WCF. I don't think that will every migrate either.

(yes, there are ways to replace WCF if you - and these examples don't require that - ignore transaction support, but it's a nightmare to migrate as far as I can tell .. and you end up with a product that looks exactly the same to the customer)

I've dabbled in .Net core since its inception and would love to use it more, but the whole WCF story was usually a deal breaker for usage at work unfortunately.

Re: .NET Core 3.0 Concludes the .NET Framework API Porting Project

#49

Post by pjmlp »

jmkni wrote: post #44
pjmlp wrote: post #20

Earlier quoted context omitted.

For our customers, we still don't bother with it beyond a couple of toy projects. Most of our customers are doing transitions to .NET Framework 4.7.1 and 4.7.2 from 4.5 and such, .NET Framework 4.8 still isn't a viable option for them, and plenty of in-house, and third party libraries they depend on aren't yet on .NET Core. By .NET 5, they might start moving into Core infrastructure. And for those teams the multi-pla…

Serious question, what makes 4.7.1/4.7.2 viable, but 4.8 not? Major breaking changes?

Validation through IT images.

Until IT certifies server images with .NET Framework 4.8, it doesn't get green light for new projects.

So is the nature of enterprise computing, I know a couple of customers still using Red-Hat Enterprise 5 on their servers.

Post reply on HN