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

.NET Core 3.0

devblogs.microsoft.com

Post reply on HN
Print view View original

161–170 of 183 posts

Re: .NET Core 3.0

#161

Post by mieseratte »

keithnz wrote: post #154
mieseratte wrote: post #145

Earlier quoted context omitted.

Having just come into a .NET shop in the last couple months, having spent much time with Spring / Java the documentation and clarity of what to use is troublesome. I really expected Microsoft to have great documentation, but sadly I’ve not found it great. So far I’ve done some WCF SOAP work, and an ASP.NET MVC 5 application. Figuring out what the latest frameworks and tools is a bit of legwork. Things aren’t always c…

its very simple to get .net core DI working, shouldn't be much code other than registering your types / service. await new HostBuilder().ConfigureServices((context, services) => { // services.AddTransient.... }).UseConsoleLifetime().Build.RunAsync()

I’m talking DI for ASP.NET MVC 5, non-Core.

That required a custom provider (trivial), and non-obviously a custom ControllerFactory as I picked Core DI instead of a more fully-fledged solution.

Unfortunately there is very little obviousness in documentation and germs often get conflated and confused. Perhaps this is MS trying to get me to take one of their infamous certification courses?

Re: .NET Core 3.0

#162

Post by nathanaldensr »

fortran77 wrote: post #26
hmexx wrote: post #13

List of performance improvements is mind-boggling: https://devblogs.microsoft.com/dotnet/performance-improvemen... How could a mature standard library / frameworks have so much performance gains to be had?

The "core" library was designed for portability and it's not as old as the .NET used for Windows desktop development, which is very mature and very performant.

One can hardly call .NET Core "a library." It's an API surface area (.NET Standard), a cross-platform implementation of said surface area (.NET Core), a cross-platform runtime (CoreCLR), and a CLI tool (dotnet). It's already introduced numerous performance enhancements over .NET Framework (e.g., Span, Memory, and the runtime itself).

IMO, .NET Framework should be relegated to the dustbin of history. There is no longer a reason to use it unless you are writing legacy code (which, granted, is a legitimate reason in many cases). For greenfield projects, I hope you're using .NET Standard and .NET Core.

Re: .NET Core 3.0

#163

Post by nathanaldensr »

gameswithgo wrote: post #121
fortran77 wrote: post #27

Earlier quoted context omitted.

The "proprietary" .NET was very performant. It's the new "open" one that has to catch up.

You have posted something along these lines twice, it is not correct. .NET Core has been better performing than Framework from the start. You may be thinking of Mono.

Just an aside: Thanks for using "better performing" and not the non-existent word "performant." ;)

Re: .NET Core 3.0

#164

Post by Sammi »

ygra wrote: post #135
grokys wrote: post #61

Earlier quoted context omitted.

We're trying to do that over at https://github.com/AvaloniaUI/Avalonia if you're interested. Doesn't have MS (or any other company's) backing, and is still in beta, but quite usable for creating x-plat apps. You can see some projects built on it here https://github.com/AvaloniaUI/Avalonia/wiki/Projects-that-ar...

I was surprised when the PowerShell team announced that Out-GridView made a reappearance in PowerShell Core, built with Avalonia. So at least someone at Microsoft took notice. I'm really rooting for the project to gain some support. Right now I'd love to try porting our custom UI component at work to Avalonia, just to try it out. But that's time not well invested in something with little backing and potentially few c…

Announcement here: https://devblogs.microsoft.com/powershell/out-gridview-retur...

Re: .NET Core 3.0

#165

Post by james_s_tayler »

gtsteve wrote: post #25
avgDev wrote: post #23

I have been developing in .Net MVC 5 and now the last 6 months in .Net Core 2.1. Core is pretty awesome, I would say the learning curve is pretty high, but I'm very satisfied. Previously, I used Java in school. The .Net stack offers a lot of jobs in enterprise companies, if you are someone that dislikes SV mindset. Also, Visual Studio is an insane IDE. Although, I recently did have some nasty bugs but updates are com…

VS is very good but I've been using Rider since the start of this year for most work, I found it to be a very strong competitor.

Our team uses Rider at work. We love it. The UX blows VS out of the water. Nice and fast too. Unit tests are a first class citizen in Rider too.

Re: .NET Core 3.0

#166

Post by james_s_tayler »

tabtab wrote: post #76
avgDev wrote: post #23

I have been developing in .Net MVC 5 and now the last 6 months in .Net Core 2.1. Core is pretty awesome, I would say the learning curve is pretty high, but I'm very satisfied. Previously, I used Java in school. The .Net stack offers a lot of jobs in enterprise companies, if you are someone that dislikes SV mindset. Also, Visual Studio is an insane IDE. Although, I recently did have some nasty bugs but updates are com…

Re: I would say the learning curve is pretty high If you had to rank and list the top rough spots in the transition, what would they be? Entity-Framework changes are often cited, but what else is different enough?

Rough spot for me is the way Startup.cs works. I mean, I'm glad it works at all, but I find the UX a bit nasty compared to how to configure SpringBoot applications.

It just feels very clunky in comparison. I have to remember so many things, which I invariably can't so I have to look them up.

I find EF Core pretty straightforward.

Re: .NET Core 3.0

#167

Post by james_s_tayler »

manigandham wrote: post #116
thrower123 wrote: post #55

Earlier quoted context omitted.

I fail to see what the point of trying to use VS Code for .NET development would be. I suppose if you like tying one hand behind your back and making things more difficult for yourself for some reason. Or maybe you like cobbling together a rickety pile of plugins. If cost is a concern, there's Rider or even MonoDevelop.

OmniSharp is the official C# plugin and all you need for .NET projects, and it's usually installed by default. VS Code starts faster, runs lighter, and provides 80% of the functionality of VS for most major products, and it's getting better every release. I find it more productive than VS for typical web projects.

For proper .NET projects I've used both VS Code, VS and Rider.

VS Code doesn't come close.

I use VS Code when doing front end stuff with Vue/TypeScript and I love it for that, but .NET Core was painful on VS Code compared to Rider.

Re: .NET Core 3.0

#168

Post by james_s_tayler »

EnderMB wrote: post #159
untog wrote: post #126

Earlier quoted context omitted.

The ecosystem is what drove me away from C# (as well as not wanting to do enterprise work). I started dabbling with Ruby and Node and the sheer number of free third party libraries blew my mind. C# simply didn't compare.

This is a very weird criticism. I'm a Ruby dev, but I spent eight years working with C#, and I can't remember any times where a Ruby gem was more readily available than a NuGet package. If anything, I'd say there's less choice in the Ruby world, especially in the data science and ML fields.

Depends. I think it's valid. There are a tonne of libraries available in both ecosystems but I find they tend to optimize for different things.

I came from the Java ecosystem to .NET and even they are different. The .NET ecosystem was held back a little by the lack of embracing open source at the beginning and being super commercially focused. So things like finding a good library for easily working with PDF will set you back $400 rather than just using the defacto library that everyone has used forever and is free. I've encountered that with PDF libraries, rules engines, workflow engines, job scheduling libraries.

It's still a decent ecosystem, it just is different because of its roots.

Re: .NET Core 3.0

#169

Post by james_s_tayler »

FlorianRappl wrote: post #108
smush wrote: post #102

Earlier quoted context omitted.

It's so amazing to me how many features from F# or other functional programming languages make their way to C#, and the devs who were otherwise never gonna try those features use them because they are 'normalized'. I do wish people would give the language that has (relative to this ^ trend) 'already arrived' a chance.

That's not the root of the problem. Personally, I wish MSBuild would be more powerful and would allow mixed compilation where some files are in C#, some in F# (or VB.NET or some other language targeting the CLR). Right now most companies (in the .NET world) just run on C# and no one tries anything new except when it arrives in C# (and even then its a struggle - even though the situation has improved a lot in recent y…

I thought you could actually do that already?

I watched a talk about F# on YouTube recently and the guy said they used F# for domain logic and C# for plumbing code and he showed them working together...

Re: .NET Core 3.0

#170

Post by rafaelvasco »

darzu wrote: post #122
rafaelvasco wrote: post #86

When I was in University people loathed .NET and idolized Java. Back then I choose C# instead of Java for my main language/toolset; People thought I was crazy. That was 10 years ago. So happy to see how much C# ecosystem has improved and keeps improving; Only thing missing for me is an official full featured C# to C++ transpiler; Only way, right now, of reaching game console platforms is by converting from C# to C++…

Or use Unity?

Yeah. That or using Monogame's Brute compiler. But a standard way would be good to have;
Post reply on HN