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

61–70 of 317 posts

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

#61

Post by merb »

manigandham wrote: post #37
Dolores12 wrote: post #10

>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

HttpClient is fast and efficient, and the built-in cookie container handles all the standard functionality, although many users just read and handle the cookie header directly. This RFC seems to be all about rejecting certain cookies under some very specific security rules. How impactful is this really? Is this affecting your app somehow?

especially since you need to enable the cookie container functionality manually and you can override it by yourself

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

#63

Post by Dolores12 »

manigandham wrote: post #37
Dolores12 wrote: post #10

>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

HttpClient is fast and efficient, and the built-in cookie container handles all the standard functionality, although many users just read and handle the cookie header directly. This RFC seems to be all about rejecting certain cookies under some very specific security rules. How impactful is this really? Is this affecting your app somehow?

Well, you expect http library to be as good as everywhere else.. like python requests. When library is not updated due to app compatibility issues i would not call it modern. It is good enough for basic use, tho.

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

#64

Post by Dolores12 »

merb wrote: post #61
manigandham wrote: post #37

Earlier quoted context omitted.

HttpClient is fast and efficient, and the built-in cookie container handles all the standard functionality, although many users just read and handle the cookie header directly. This RFC seems to be all about rejecting certain cookies under some very specific security rules. How impactful is this really? Is this affecting your app somehow?

especially since you need to enable the cookie container functionality manually and you can override it by yourself

or use different language with good library that support 8-year old RFC.

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

#65

Post by manigandham »

Dolores12 wrote: post #63
manigandham wrote: post #37

Earlier quoted context omitted.

HttpClient is fast and efficient, and the built-in cookie container handles all the standard functionality, although many users just read and handle the cookie header directly. This RFC seems to be all about rejecting certain cookies under some very specific security rules. How impactful is this really? Is this affecting your app somehow?

Well, you expect http library to be as good as everywhere else.. like python requests. When library is not updated due to app compatibility issues i would not call it modern. It is good enough for basic use, tho.

HttpClient supports http2, the latest protocol features, has been rewritten in managed code with sockets, and includes advanced handling to balance connection lifetimes with DNS updates. It's about as modern as it gets and we run 10 billion requests per day through this code without issue.

How does a lack of support for an RFC (which is still being revised) that outlines where a cookie should not be accepted in edge cases mean the HTTP library is not modern? Where are you running into this issue in a real app?

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

#66

Post by manigandham »

Dolores12 wrote: post #64
merb wrote: post #61

Earlier quoted context omitted.

especially since you need to enable the cookie container functionality manually and you can override it by yourself

or use different language with good library that support 8-year old RFC.

C# is a language but .NET is a runtime and standard library. If this issue is really such a problem, you can use any of the dozens of open-source libraries available or just implement your own cookie container that follows this RFC in about a day.

It sounds like you're picking on a strange issue to disparage .NET without any real experience in it.

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

#67

Post by sword_smith »

manigandham wrote: post #23
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 n…

It would seem to me that you wouldn't be able to mock all the classes if you followed this strategy.

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

#68

Post by sword_smith »

enlyth wrote: post #56
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 ?

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

This setup is also what Google Cloud is using for their App Engine.

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

#69

Post by manigandham »

sword_smith wrote: post #67
manigandham wrote: post #23

Earlier quoted context omitted.

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 n…

It would seem to me that you wouldn't be able to mock all the classes if you followed this strategy.

Well do you really need to mock everything? And if so, how is that different than any other stack?

Most of the time this is just "enterprise patterns" without any thought about whether it's worth it. I've seen too many small LOB apps that have 5 tiers of code for no reason.

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

#70

Post by sebazzz »

EnderMB wrote: post #31
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 :)

There are some similarities to Python 3 in .NET Core adoption. I know plenty of people that would love nothing more than to be up to date and to start using .NET Core, but many of them rely on certain libraries that simply aren't there yet. I know a load of Umbraco devs that are eager to make the jump, but until their CMS supports it, they're kinda stuck if it's a dependency.

Many libs already support it. But the end-users, the web applications, are the problem. If you haven't properly separated business logic from UI, which might very well be the case if your project budgets aren't too high or other causes, you will have a rewrite on your hands instead of a port. A rewrite which is, especially on low budgets, not worth it.
Post reply on HN