Live data from Hacker News

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

github.com

51–60 of 317 posts

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

#51
post #9

I've tried to port a MVC project to .NETCore 2 a while ago, it was pretty painful mainly due to lack of @helper syntax in views (everything which relied to @helper had to be changed). Also, from what i saw, nobody is actually in a rush to "move" to .NETCore, most big shops still rely on .Net Framerwork , i still do some occasional work on a project which is using .Net Remoting :)

I think this news marks the point from which we may see the move happening.

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

#52
post #34

Earlier quoted context omitted.

He wants top level functions. He wants to not have to write classes if he thinks the domain doesn't need modelling as objects.

You can have static classes that can contain nothing but static members - so effectively a namespace with no instantiation of that class allowed so no objects.

I know, but many people dislike boilerplate code.

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

#54
post #41
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.

Yes, if things keep changing around or is hard to find, that's annoying but I see this as a separate problem from a bad pace and inconsistency. Nothing here in particular hinders good and well researched design.

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

#56
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 ?

I am using nginx as a reverse proxy to kestrel in production on one of my projects and it seems to be working great so far

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

#57

>With .NET Core 3.0, we’re at the point where we’ve ported all technologies that are required for modern workloads .net HttpClient is based on outdated cookies RFC, RFC6265(that is 8 years old) is yet to be supported [1]. And what can you do today without good http library? [1] https://github.com/dotnet/corefx/issues/29651

The HTTP library is super easy to use and is very fast. I would not say that this issue makes the library bad.

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

#58
post #47
post #26

Earlier quoted context omitted.

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.

Yes, that's what I meant. The use of the term "API" for a single public code element is something I have not come across in any other language community, hence the clarification for those who are not familiar.

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

#59
post #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…

One of the key problems of our time (besides antibiotics resistance, climate change, lack of affordable housing, poverty, rise of nationalism and totalitarian ideologies, mass surveillance, etc) seems to be the impossibility of reliably generating reference counted code from code written for a tracing GC.

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

#60
post #29
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…

> My wishlist for C# is short: [...] F# provides all of them, is shipped with .Net Core 3.0 and also works great on Linux.

Works for personal projects and is certainly a joyful experience. But recruiting developers is near impossible - which is key for the kind of projects/companies I work with.
Post reply on HN