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

131–140 of 317 posts

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

#131

Post by asp_hornet »

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 :)

In my experience, it’s the opposite. If you’re not migrating your apps to core your hiring pool is going to be getting significantly smaller and smaller over the next couple of years. Think Swift vs Objective C or old jquery heavy websites vs transpiled ES6.

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

#132

Post by pjmlp »

zaphirplane wrote: post #124
pjmlp wrote: post #12

Earlier quoted context omitted.

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 ?

Long story short, that you kind have to assemble from blog posts, forum comments, between the lines articles and so on.

Longhorn was to be built on top of .NET and there were lots of issues, regarding performance, stability and what not.

Apparently it was more a thing of WinDev (owner of Windows and C++) and DevTools (owner of VS and .NET) each pulling to their side instead of collaborating.

As proven later by Singularity and Midori it was an achievable goal, when everyone on the team believes on the end goal.

Instead Sinofsky team took over, several ideas were dropped, others were reborn in .NET 3.x like WPF, and Vista came to be.

Many of the .NET (Longhorn) libraries reappeared in Vista and Windows 7 as COM libraries.

See Project Hilo sample, https://blogs.msdn.microsoft.com/jasonz/2010/06/06/project-h...

Later WinRT was born, which is an improvement over COM, using IInspectable alongside IUnknown, and .NET Metadata instead of the old COM type libraries.

Curiously similar in concept to Ext-VOS, which was in the genesis of .NET, before CLR came to be.

https://blogs.msdn.microsoft.com/dsyme/2012/07/05/more-c-net...

So WinRT (Win 8.0), eventually became UAP (Win 8.1) and now it is UWP (Win 10).

Contrary to many Windows 10 haters belive, UWP isn't tied to the store and each Windows 10 release brings more Win32 "legacy" APIs into UWP.

The next generation COM based runtime with interoperability across C++, .NET, JavaScript, Delphi and every other language capable of understanding COM projections.

Ah, and thanks to the contributions initially started by Kenny Kerr, which ended up joining the Windows team, the C++/CX language extensions got replaced by C++/WinRT a C++17 framework for UWP.

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

#133

Post by victorNicollet »

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

Using cookies in HttpClient strikes me as a rare situation.

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

#134

Post by saberience »

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?

You are being over the top and quite frankly ridiculous. I've been using .Net Core in production since its initial release while working for a famous games company (which you probably heard of) and now for a multi billion dollar FinTech firm, and the whole time I have been using HttpClient or libraries using HttpClient for connecting to services/apis.

If your whole reason for not using .Net Core is based around this weird and honestly unimportant edge case, all that tells me is that you have a strange bias against the framework for some other reason and looking to nitpick.

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

#135

Post by saberience »

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.

I've been using .Net Core in production since its initial release. First company was a well known AAA games studio running backend micro-services in docker containers using .Net Core. Currently at a unicorn FinTech (2B valuation) where literally every backend service is .Net Core 2.2 (soon 3) running in docker containers and the containers are orchestrated in AWS ECS. Works amazingly.

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

#136

Post by scarface74 »

EnderMB wrote: post #128
oaiey wrote: post #104

Earlier quoted context omitted.

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

I don’t care about being able to develop .Net apps on Linux. Being able to deploy to Linux is a game changer especially in the cloud. Anytime that you add Windows to a cloud environment you get hit with the triple whammy of slow startup times, increased licensing costs and increased resource requirements.

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

#137

Post by vbezhenar »

fauigerzigerk wrote: post #116
pjmlp wrote: post #83

Earlier quoted context omitted.

Nah, that key problem will eventually be sorted out with a couple of generational changes.

I'm serious (even if it may not sound like it). COM is a fantastic platform, because it provides simple and efficient interoperability between language runtimes. But code written for tracing GCs cannot be automatically transformed into COM's (or any) reference counting scheme. And that's why we have this endless tug of war between those who want to build on top of COM versus those who want to build on top of .NET. It…

May be I don't understand something, but how does it differ from e.g. operating file handles? For example in Java you're supposed to use try-finally to close file handle. You should do the same with reference-counted objects, just manage their lifetime manually. And finalizers will close it for you if you forgot to do that (that should be considered as a bug, but not very serious).

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

#138

Post by nikanj »

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?

See a few comments up this very comment chain. They’re hidden because they look dated, regardless of their usability

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

#139

Post by Crinus »

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…

> Windows userland is being rewritten in COM since Vista

I am not sure "rewritten" is the proper word as this implies replacement, but in reality nothing gets replaced (at least as far as the user/developer facing stuff go) and the new stuff are added on top (or alongside, depends) the existing stuff.

Also i'm not sure if the whole "exposing new stuff in COM" thing is a good idea overall. The classic Win32 GUI APIs might not provide much functionality on their own, but the plain C APIs make them both understandable by pretty much everyone and fairly easy to use by pretty much everywhere. I haven't seen much COM use on the wild since the turn of the millenium (outside of the new UWP stuff in Windows Store but really the UWP/Windows Store seems to be a different world on its own that got itself attached to the regular desktop Windows world... and even then i do not really know of anyone who uses anything from there). The most common comment i read about COM is using it to control Office but that's about it (technically DirectX APIs are also COM but in practice you do not really use much of it).

As an example, Windows had a COM API for creating ribbon-like interfaces ever since Windows 7/Vista SP2 yet pretty much every framework out there (including MFC) reimplements their own ribbon using Win32 primitives instead of using the native one.

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

#140

Post by scarface74 »

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 are mostly a web SASS that was traditionally written in C# .Net Framework/ASP.Net MVC. All of our new code is .Net Core/React we are trying to move toward Docker and Fargate (AWS serverless Docker). We really want to get off our dependency on Windows.

In general, .Net framework is legacy. I see very little green field development being done with .Net framework.

Language level compatibility doesn’t help. There are so many differences between ASP.Net and EF6 between .Net framework and .Net Core that it isn’t an easy lift. But, MS did the right thing by not worshipping at the alter of backwards compatibility for a change.

Post reply on HN