Live data from Hacker News

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

github.com

11–20 of 317 posts

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

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

> adoption of .NET core on standard line of business applications

This is rather anecdotal but in my little area of the world there is little. .Net is moving too fast and too impractical to really be worth it on enterprise these days. The main problem for us is the libraries for handling thing like data-formats.

Linq-to-sql is still better than Entity Framework from a time to market perspective, but both of them are really, really slow. XML interpreters reminds me of learning JAVA back in the early 00’s, they execute well enough but you need two million lines of code to do what Python does in 20. Working with SOAP and SAML often requires you to build additional parts on top of the fairly terrible APIs and some older stuff, that used to be in .Net has simply disappeared into unmaintained third party libraries. Connecting up Microsoft’s own System Center (2012) has gone from being a simple service reference to you having to build your own library because Microsoft moved to Azure. Even official libraries for AD integration are half finished and require you to build your own service APIs to look up stuff like unique IDs.

.Net Core is really good at building CRUD services and really bad at everything you actually need in Enterprise situations because almost nothing in the real world actually requires that.

Luckily both Microsoft and Azure are treating things like Python as first class citizens both on Windows Servers and in Azure. Their own Powershell has become a much more powerful tool than C# has as well, so it’s not like I dislike Microsoft at all, it’s just that .Net has spent the past decade becoming less and less useful for what we need it to do.

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

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

Windows userland is being rewritten in COM since Vista, as the Windows team picked up the Longhorn ideas and used them in COM after winning the WinDev vs DevTools politics, I doubt they will change route.

The best we can hope for is that with the new AOT/JIT infrastructure, it gets more equal footing with C++/WinRT in platform APIs.

After all, it has won the UI, MFC is legacy and XAML/C++ doesn't have much uptake as most companies rather do C++/COM and then consume them from .NET for the UI part.

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

#13
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 .NET Core for a few new projects. Our situation is a bit different as we build bespoke software for a wide range of clients. We're pretty satisfied with it.

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

#15
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

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

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

I find the verbosity complain rather strange.

Then again, I rather use maintainable programming languages, instead of writing hieroglyphs.

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

#17
post #14

> ...increased the number of .NET Framework APIs ported to .NET Core to over 120k, which is more than half of all .NET Framework APIs I don't know .NET at all and the numbers there seem mind boggling. Can someone put this into some kind of context?

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.

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

#18
post #14

> ...increased the number of .NET Framework APIs ported to .NET Core to over 120k, which is more than half of all .NET Framework APIs I don't know .NET at all and the numbers there seem mind boggling. Can someone put this into some kind of context?

It refers to the API surface area (classes, methods, namespaces available in the standard library) from .NET Framework, the Windows-only runtime that has been developed for the last 15 years.

.NET Core is the new cross-platform runtime and now supports more than half of all the API surface available from the older framework. The number itself isn't anything special but just denotes how big the standard library is.

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

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

>Btw, Linux as a deployment platform works quite well.

What are you using in production for Linux ? Kestrel + Nginx ? Any problems encountered with this setup ?

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

#20
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-platform part of .NET Core isn't that appealing, because UNIX deployments are already covered by the Java teams anyway, with products whose .NET counterparts are yet to be 1:1 available.

Post reply on HN