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

121–130 of 317 posts

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

#121

Post by cm2187 »

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.

And also items from the old control panel don't appear any more when you search in the start menu.

Which would be ok if they had been replaced by an equivalent in the new menu. But they have not. So what is the point in hiding them?

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

#122

Post by daniel-levin »

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.

Well, requests is a third party library. I don't like Python's standard library's HTTP APIs. I think that's a common sentiment. Similarly, you can get a solid third party its client for dotnet [1]. .NET core certainly has its shortcomings. I'm going to rattle of a list of other high quality libraries that address the .NET core shortcomings for me personally:

1) Dapper - https://github.com/StackExchange/Dapper

2) DbUp - https://dbup.readthedocs.io/en/latest/

3) Autofac - https://autofac.org/

The Kestrel source code expanded my view of what was possible in C# with respect to low level operations on memory (check out the fixed statement [2]).

A part of me doesn't want to like Microsoft because of their anti-competitive behavior in the past and crappy developer experiences from 10 years ago. Now, I sound like a Microsoft shill because of how good .NET core is.

[1] https://github.com/restsharp/RestSharp

[2] https://docs.microsoft.com/en-us/dotnet/csharp/language-refe...

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

#123

Post by manigandham »

sword_smith wrote: post #118
manigandham wrote: post #69

Earlier quoted context omitted.

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.

Probably not but it is in my opinion very nice to have the ability to mock evertyhing if and when you need it.

You always have the ability. It's just writing code. But you should only do it when you need to.

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

#124

Post by zaphirplane »

pjmlp wrote: post #12
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…

Windows userland is being rewritten in COM since Vista, as the Windows team picked up the Longhorn ideas and used them in COM after winning the WinDev vs DevTools politics, I doubt they will change route. The best we can hope for is that with the new AOT/JIT infrastructure, it gets more equal footing with C++/WinRT in platform APIs. After all, it has won the UI, MFC is legacy and XAML/C++ doesn't have much uptake as…

Hey for people that don’t follow windows internals and politics closely, what did the devTools champion ? What are the longhorn ideas that are getting into windows ?

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

#125

Post by gexla »

cm2187 wrote: post #121
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.

And also items from the old control panel don't appear any more when you search in the start menu. Which would be ok if they had been replaced by an equivalent in the new menu. But they have not. So what is the point in hiding them?

Let me have their pretty UI. If you want to geek out, there's Powershell.

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

#126

Post by tonyedgecombe »

surban wrote: post #29
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.

It doesn't give you structural typing, it's still normative:

https://stackoverflow.com/a/3137561/57094

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

#127

Post by tasogare »

denisw wrote: post #58
ptx wrote: post #47

Earlier quoted context omitted.

I think the point was that often "an API" means a larger collection of functions, classes, properties, etc. Like the COM API, the DirectX API, the MFC API and so on.

Yes, that's what I meant. The use of the term "API" for a single public code element is something I have not come across in any other language community, hence the clarification for those who are not familiar.

I've seen it before in Apple communication. I hate this usage. It doesn't cost a lot of keystrokes to write "API members" which is more precise.

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

#128

Post by EnderMB »

oaiey wrote: post #104
EnderMB wrote: post #31

Earlier quoted context omitted.

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.

Just with the difference, that there is not 2/3 culture split here. Everyone agrees that .NET Core is the future and should be used. The universal cloud adoption (e.g. AWS Lambda), containerization and Linux deployments are so huge selling points for .NET Core. People are hold back because of deprecated tech and because no one touches a running system without need. And maybe that black matter developers just do not k…

For reference, I'm mostly talking about brand-new projects, and purely from my perspective as a former .NET dev that still spends time with the local .NET community.

I've not met a single .NET dev that doesn't want to use .NET Core. Hell, if anything, a lot of them would love the opportunity to use .NET on a Unix system, and to use established tooling not available on Windows. The problem is that the tools they use aren't ported yet.

Umbraco is a key example, as the most popular .NET CMS in use today. It's a great CMS, but we're at least 1-2 years away from a .NET Core implementation, and probably even longer if we're hoping for a first-class Postgres/MySQL backed implementation. Until then, as you've rightly said, there's no need to switch to .NET Core.

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

#129

Post by manigandham »

Dolores12 wrote: post #82
manigandham wrote: post #65

Earlier quoted context omitted.

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…

> Where are you running into this issue in a real app? I had discovered few bugs in cookies handling myself, compared behavior to competitors and moved on. If cookies handling is not enough, i came across inconsistent behavior on different platforms: on Windows it uses WinHttpHandler, on Linux its curl lib(if i remember correctly). And they both handle edge cases differently.

HttpClient uses sockets in managed code since .NET Core 2.1 which was released in Oct 2018: https://docs.microsoft.com/en-us/dotnet/core/whats-new/dotne...

There shouldn't be any platform issues unless you're using an even older version or manually forcing it. What bugs in cookie handling did you encounter? This is very widely used code and the team is responsive so if you can document the issues then they can help.

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

#130

Post by manigandham »

Dolores12 wrote: post #86
manigandham wrote: post #66

Earlier quoted context omitted.

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.

No, i just didn't like the wording in the original post mentioning all 'modern workloads' , while ubiquitous thing like cookies in httpclient is still not according to 8 year old standard. Does it make any sense now?

Modern workloads refers to the kind of applications commonly built today, like http/json/grpc webservices running in containers.

And yes the HttpClient is modern. Your entire argument so far has been a single RFC issue that is labeled up-for-grabs because it's so minor and doesn't really affect anyone. Claiming the http functionality and the whole stack isn't modern because of it just doesn't add up.

Post reply on HN