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

21–30 of 317 posts

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

#21

Post by manigandham »

mariusmg wrote: 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 find the opposite to be true. Many companies are moving to .NET Core, especially the independent dev shops. Cross-platform, easier to develop, faster and cheaper to run, and now supports desktop APIs.

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

#23

Post by manigandham »

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…

Are you making interfaces for everything? Just register and use the class with constructor injection. All those layers of indirection just waste time.

What would change with functions outside of classes? You already have anonymous functions/lambdas, static classes and extension methods if it's about instantiation overhead, and local (nested) functions. Can you explain a scenario where this doesn't work for you?

For namespace declarations, you can just use the same namespace on all classes if you want to keep it simple, and that kind of flexibility isn't available if you use file structure.

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

#24

Post by tonyedgecombe »

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.

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

#25

Post by sytelus »

asplake wrote: 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's massive and includes all kind of things from localization, networking, file system, threading, compiler, graphics, cryptography, web, text processing, XAML, OS etc APIs.

https://docs.microsoft.com/en-us/dotnet/api/?view=netcore-3....

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

#26

Post by sytelus »

denisw wrote: post #17
asplake wrote: 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.

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?

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

#27

Post by [deleted] »

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.

[deleted]

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

#28

Post by codeulike »

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…

- Allow functions outside of classes

What do you mean? Isn't that just anonymous functions?

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

#29

Post by surban »

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…

> My wishlist for C# is short: [...]

F# provides all of them, is shipped with .Net Core 3.0 and also works great on Linux.

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

#30

Post by manigandham »

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.

Last 5 startups have used .NET, all of them have migrated and all new projects are on .NET Core. Every major dev shop I know starts new projects on Core.

It's mostly legacy and enterprise apps but it wasn't until .NET Core 3.0 (released last month) that it was viable to migrate everything perfectly anyway so it'll take time for that to filter through.

This is nothing like Python 2/3. .NET Standard has been out for a while and all the major libraries are compatible with both runtimes, and that now includes desktop APIs too.

Post reply on HN