.NET Core 3.0 Concludes the .NET Framework API Porting Project • Hacker News Board

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

#191

Post by celticmusic » Tue, Oct 15, 2019, 1:51 PM UTC

gnud wrote: post #41

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.

same here. I still prefer the old control panel. They hid everything behind "usability". I'm sure for a lot of people it's more usable, but for me it's just more painful.

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

#192

Post by marsrover » Tue, Oct 15, 2019, 1:53 PM UTC

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've been using .NET Core since RC1 and first deployed to production when version 1 was released.

From what I've seen, all new projects are being done in .NET Core, and legacy apps are not really being migrated over. .NET Core 3 might fix a lot of these issues, but in the past there were a lot of library unavailable in Core that you could only use in Framework.

I haven't had a recruiter mention Framework in over a year now, I don't believe. It's all Core now.

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

#193

Post by mumblemumble » Tue, Oct 15, 2019, 1:55 PM UTC

thrower123 wrote: post #188

While I'm happy to hear this on one level, as it likely means that .NET Core is finally going to be approaching some levels of stability that allow it to be used in earnest for production usage, I'm somewhat dismayed. There's still a lot of things missing from it that the 4.X full framework version had, and this feels like it is the door slamming shut on hopes that existing code could be seamlessly upgraded without a…

FWIW, the decisions on what not to port that I'm aware of seem to make sense.

WCF, for example: Its a legacy technology that is also horribly complex and never really took off. It was never really a good solution if you wanted cross-platform RPC, and therefore has a userbase that doesn't overlap much with the people they're trying to attract with .NET Core. If you're trying to migrate to .NET Core in order to go cross-platform, you probably want to be migrating off of WCF, anyway. And if that's not true of you. then .NET Framework 4.8 probably still suits your needs, anyway.

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

#194

Post by thrower123 » Tue, Oct 15, 2019, 1:57 PM UTC

pjmlp wrote: post #43

jmkni wrote: post #39

Earlier quoted context omitted.

+1 for Rider. It's basically ReSharper.

Including resource usage! As anything on top of InteliJ.

One of the nice things about Rider, though, as opposed to ReSharper, is that it can be run as 64-bit, and you can control the size of the Java memory heap, rather than being jailed inside the 32-bit devenv.exe process.

Visual Studio with Resharper chokes and dies pretty badly when you get into large solutions with 100k+ LOC and many projects. For years I've been seeing problems when memory usage gets close to 2GB, and the editor and intellisense starts getting laggy and unresponsive. For whatever reason, it is really bad if you have web applications with JS in the mix, to the point where I have resorted to just running WebStorm in parallel to do any front-end work.

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

#195

Post by UglyToad » Tue, Oct 15, 2019, 1:57 PM UTC

ThrowMeAwayOkay wrote: post #184

UglyToad wrote: post #146

Earlier quoted context omitted.

I'm currently building an open source (not copyleft) PDF library for.NET standard [0] and I'd be interested to hear more what you need on the document generation side. The current generation API for my library is extremely limited because I've never needed one but you are the perfect market research participant. It's an API I'm actively looking to improve. PDF/A compliance is probably quite a way off though. [0]: htt…

I have a .NET Core web app that needs PDF creation abilities. Can I be your market research participant as well?

Of course. Most of the current API focuses on data extraction because that was my area of work when I started the project but I think creation is the more common problem so its good to hear as many use cases as possible.

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

#196

Post by stoobs » Tue, Oct 15, 2019, 2:00 PM UTC

pjmlp wrote: post #81

lultimouomo wrote: post #74

Earlier quoted context omitted.

JetBrains stuff does feel sluggish and occasionally hangs on my 2016 XPS-13 with 8G of ram. It gets the job done, but it's not pleasant. On my new Ryzen 3600 with 32G of ram it runs smooth. So if you go for JetBrains, I definitely advise not to cheap out on the hardware. Rider on Linux was very good for me, working on C# azure functions.

32G?!? Where does one find such employers??? Not to mention how crazy it sounds having 32GB for an IDE. Visual Studio, Netbeans and Eclipse run perfectly fine with 8 GB.

All the Dev machines where I work have been 16GB for years, I wouldn't be surprised if we jumped to 32GB in the next hardware refresh.

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

#197

Post by scott00 » Tue, Oct 15, 2019, 2:05 PM UTC

privateSFacct wrote: post #179

scott00 wrote: post #166

Earlier quoted context omitted.

If you were trying WinForms, the designer does not yet work for .NET Core apps. The WPF designer is supposed to work with .NET Core, but there was a bug in it in the first VS release that might have been the cause of your issue[0]. I also had problems doing anything other than toy WPF projects. IMO the .NET Core support for the GUI frameworks is not ready for prime time. Building GUI apps in .NET Framework is still a…

Very helpful. I thought WPF / Core was the recommended / modern approach. I just fired up an attempt using Windows Forms / Net Framework after scrolling down to that combo. It looks good so far.

Yeah, I think the Microsoft messaging would naturally lead you to that conclusion, though generally they avoid saying it explicitly. I think in a year WPF and WinForms will probably work great under .NET Core, but I wouldn't use either for real work right now. My recommendation would be to use .NET Framework for GUI work right now, but do it in such a way that the upgrade path is easy. The way to do that is to create the project under .NET Core, and then hand edit the project file to change the element from "netcoreapp3.0" to "net472". That will give you the new project file format and make it easy to upgrade when they finish getting the bugs out. The other main thing you should do is to create any libraries as .NET Standard 2.0 libraries, which work with both .NET Framework and .NET Core.

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

#198

Post by thrower123 » Tue, Oct 15, 2019, 2:05 PM UTC

tonyedgecombe wrote: post #24

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…

I keep coming back for a look every time there is a major release but it always seems quite cumbersome to me despite the fact I work in C# everyday. I ran through the Razor pages tutorial yesterday and I was surprised how heavy it all felt, I was expecting something like Flask or Sinatra. I'm a big fan of IDEs, I couldn't imagine using C# without one.

I've been quite happy using Nancy for the past several years. At the time we made the switch, it wasn't possible to use WebApi or MVC in a self-hosted OWIN web server, and our application had lifecycle constraints that made trying to run it out of IIS impractical.

But I've come to really like the way Nancy has explicit API routes, compared to the implicit conventional style, or slapping attributes all over everything. You can avoid a lot of the magical action-at-a-distance middleware behavior that seems to be increasingly common as well.

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

#199

Post by shawnz » Tue, Oct 15, 2019, 2:08 PM UTC

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…

The old control panel can never be removed, because a significant amount of legacy software integrates itself into the old control panel and therefore wouldn't be usable if they removed it.

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

#200

Post by mmavnn » Tue, Oct 15, 2019, 2:12 PM UTC

tonyedgecombe wrote: post #156

goto11 wrote: post #155

Earlier quoted context omitted.

Nominative, not normative. Nominative means "by name", i.e. you reference types by names. A structural type (aka anonymous type) does not have a name, so cannot be referenced.

Yes, I meant nominative.

It also has syntax for structural typing where needed.