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

271–280 of 317 posts

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

#271

Post by bob1029 »

jayd16 wrote: post #46
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.

Have you run into any difficulties with the GC, or are you already playing around with some of the configuration options here?

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

#272

Post by zmj »

mickdaisy wrote: post #252
LandR wrote: post #62

My biggest issue with .net core and .net in general, although .net core seems worse, is nuget issues and it causing issues with binding redirects. Seems like every project I waste hours trying to figure out the mess that nuget creates.

Same here. I've tried moving my "boilerplate side project" .NET Framework template over to the latest and greatest about once a year over the past four years and every time I hit the eight hour mark, I give up. Either my dependencies aren't supported yet, or there's some wonky versioning incompatibility, or there's some other undocumented frustration. I'm not dealing with anything wildly complex here ~ just an n-tier…

If your .NET Framework projects are in the old csproj style, first convert them to SDK style - no changes to the target runtimes or dependency versions. For asp.net, winforms, or wpf apps, this is usually the hard part.

Once the app is working with SDK style projects, then try changing the runtime to netcoreapp. Often it just works; if it doesn't, you'll get useful error messages.

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

#273

Post by [deleted] »

tonyedgecombe wrote: post #120
gnud wrote: post #41

Earlier quoted context omitted.

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.

Not only that but the new interface is becoming just as complex as the old. By the time they have finished they will be back where they started.

[deleted]

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

#274

Post by manigandham »

goto11 wrote: post #108
SideburnsOfDoom wrote: post #75

Earlier quoted context omitted.

> Allow functions outside of classes Why? You can put them in a static class, and if C# ever had this feature, it would just be syntactic sugar for a hidden static class. But that would mean optimising for "hello world" and other small script scenarios, which isn't a goal of the language design. > Adopt (files and dirs) instead of forcing namespace declarations Likewise. > Structural typing Like "dynamic" in C# 4 ? B…

Structural typing is different from dynamic typing. C# supports structural typing in the form of tuples and anonymous types. But you can't return an anonymous type from a method. This is a significant limitation. As for "free" functions: C# already recognizes the usefulness of this in the "using static" directive. This is useful for a lot more than "hello world".

Why are "free" functions useful? What actual real difference does it make compared to putting an extra word in front to call the method?

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

#275

Post by lazulicurio »

marsrover wrote: post #189
LandR wrote: post #62

My biggest issue with .net core and .net in general, although .net core seems worse, is nuget issues and it causing issues with binding redirects. Seems like every project I waste hours trying to figure out the mess that nuget creates.

I really don't understand how you're having binding redirect issues with .NET core. They're usually caused by a mixup between local packages and the GAC, which .NET core doesn't use. When you publish a .NET core application, you can publish as stand alone and see right there in the publish directory all the DLLs that are being used.

There's still plenty of ways reference resolution with NuGet can go wrong, even without the GAC.

For example, because NuGet allows packages to import .props and .targets files you can have packages that add arbitrary references that don't match your target framework or runtime. Now you could say "oh, that's the package's fault, not NuGet's", but often the reason a package includes .props or .targets files is to work around other shortcomings in NuGet.

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

#276

Post by manigandham »

wokwokwok wrote: post #92
denisw wrote: post #15

Earlier quoted context omitted.

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

Oh no, don’t do that. The vscode integration is barely beyond autocomplete, and it uses more memory than rider does. The c# story for vscode still has a long way to go before it’s even close to feature parity. (...and yes, if you scrabble enough plugins you can get more features, but you get more crashes and even more memory slurping. :/)

What do you mean? The official C# support is from the Omnisharp plugin [1].

Omnisharp is the official .NET cross-platform development support system and is used across many different interfaces (VSCode, Atom, Sublime, etc). It's powered by Roslyn [2], the C# compiler platform, and can use the same packages for analyzers and autofixes that VS uses. It also has official debugging support. This is way beyond autocomplete.

1. https://github.com/OmniSharp/omnisharp-vscode

2. https://github.com/OmniSharp/omnisharp-roslyn

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

#277

Post by merb »

Const-me wrote: post #233
merb wrote: post #88

sadly .net core still lacks a good pdf library that is not priced over the top. (and at least supports building pdfs and creating pdf/a 3's.)

I’ve just built iTextSharp LGPL for .NET Core 2.2: https://github.com/schourode/iTextSharp-LGPL It only needed a single dependency to build on.NET core, System.Drawing.Common from nuget, for Image and Matrix classes. That version has a few unfixed bugs, e.g. merged table cells are sometimes broken, but the code quality is OK on average, relatively easy to fix them if you need to.

btw. we are using it to read pdf's unfortunatly no pdf/a-3 creation support

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

#278

Post by deskamess »

manigandham wrote: post #71
mariusmg wrote: post #19

Earlier quoted context omitted.

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

We run Kestrel directly facing the internet serving http2 traffic across billions of requests per day with no issue. No need for Nginx.

Which Linux distro are you going with? Any recommendations for/against distributions.

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

#279

Post by merb »

Volrath89 wrote: post #205
merb wrote: post #88

sadly .net core still lacks a good pdf library that is not priced over the top. (and at least supports building pdfs and creating pdf/a 3's.)

Have you tried itextsharp? https://www.nuget.org/packages/iTextSharp/5.5.13.1 I've successfully used it both in .net 4.7 and .net core 2.2 to generate complex pdf structures, and it has been a great experience.

AGPL or over 4000€ per server.

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

#280

Post by james_s_tayler »

wayneftw wrote: post #150
james_s_tayler wrote: post #42

Earlier quoted context omitted.

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

Thank goodness that VSCode is a different experience! VS and Rider are a pain in the ass to setup and maintain and VSCode provides the essential UX better than just about anything else at this time. I can have VSCode installed and running with my personal settings on any OS within 2 minutes flat. I don't have to find a secret license key, login with any account, or pick through a list of 100 features in the installer…

>Thank goodness that VSCode is a different experience! VS and Rider are a pain in the ass to setup and maintain and VSCode provides the essential UX better than just about anything else at this time

I find it's the opposite. VSCode is just a very barebones editor with an ecosystem of plugins that may or may not be maintained. I always need to search through a list of hundreds of plugins to figure out which ones I need for this particular techstack.

I started using Rider this year and it's been much, much better than VS and VSCode for me. I can use it in both Windows and Linux. Search experience in Rider is my favorite part of the UX. I find VSCode clunky in comparison.

I use VSCode when doing Vue stuff. I like it for that. But I still miss the nice search UX of Rider. Maybe I need to dive deeper to see if there is a setting or another plugin that can get me that same feeling.

Post reply on HN