Live data from Hacker News

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

github.com

211–220 of 317 posts

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

#211

I never understood why they didn't port IQueryable. I never really updated my Azure functions from runtime v1 to v2 becuause of that. Dealing with Table Storage without it is a pain in the ass.

IQueryable is the base of LINQ. I think you are looking for a certain provider not for the interface.

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

#212

Earlier quoted context omitted.

If you were trying WinForms, the designer does not yet work for .NET Core apps. The WPF designer is supposed to work with .NET Core, but there was a bug in it in the first VS release that might have been the cause of your issue[0]. I also had problems doing anything other than toy WPF projects. IMO the .NET Core support for the GUI frameworks is not ready for prime time. Building GUI apps in .NET Framework is still a…

Very helpful. I thought WPF / Core was the recommended / modern approach. I just fired up an attempt using Windows Forms / Net Framework after scrolling down to that combo. It looks good so far.

Await the November update. When I remember right, they will update the designer till then.

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

#213
post #199

Earlier quoted context omitted.

The old control panel can never be removed, because a significant amount of legacy software integrates itself into the old control panel and therefore wouldn't be usable if they removed it.

They also contain decades of bodges and quick fixes to get stuff to just work - working out what they need to keep and throw away must be a nightmare.

Microsoft is gradually porting what's necessary out of the Control Panel in a controlled manner. Rather than offering 1:1 functionality to existing items in the Control Panel, they're examining and rethinking everything. The new Settings App is a cross platform legacy free future.

Certain elements will likely never be ported, like Phone and Modem, but will remain forever in the Control Panel. And the Control Panel will probably be a platform specific feature of x86/AMD64 based Windows installs.

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

#214
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…

This oldie seems relevant: http://moishelettvin.blogspot.com/2006/11/windows-shutdown-c... 1 year to build Windows Vista's new shutdown menu, with a total of 43 people somehow involved in its design. If this is how Windows developers still have to work, it's no wonder. That said, I would readily believe that the roots of this story have more to do with the complexity of modern OSes than any particulars of Microsoft c…

ChromeOS? Is that a success? Lots of concessions there I guess though.

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

#215
post #33

And yet it's not used for rockstar projects (change my mind).

It will be. Just a matter of time. As things stabilize; Unity Engine will certainly use it moving on. They could already be using it. Not certain; It just doesn't make sense starting a new project with old .NET Framework from now on;

Until everyone has put their golden eggs on .NET Core basket, it makes plenty of sense.

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

#216
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 have 3 .NET Core apps already in production in an enterprise environment but all were new projects.

We have not migrated the 4-5 .NET apps we have and don't see a pressing need yet.

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

#217
post #215

Earlier quoted context omitted.

It will be. Just a matter of time. As things stabilize; Unity Engine will certainly use it moving on. They could already be using it. Not certain; It just doesn't make sense starting a new project with old .NET Framework from now on;

Until everyone has put their golden eggs on .NET Core basket, it makes plenty of sense.

Absolutely. It depends on the project and situation. But it'll start making less and less sense. Personally I've moved on at .NET Core 2. Never looked back; But my area is game development. Most people on .NET are doing Web Development; There it could still make sense to stay at old and proved .NET Framework;

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

#218
post #41
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.

I call it the Windows control fractal. Each new version of Windows requires clicking through a totally new UI layer to get to the previous version's control panel. Finally you arrive at the Windows 95 settings program you were trying to get to in the first place.

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

#219
post #62

My biggest issue with .net core and .net in general, although .net core seems worse, is nuget issues and it causing issues with binding redirects. Seems like every project I waste hours trying to figure out the mess that nuget creates.

.net core is definitely better than .net framework in regards to nuget issues in my experience.

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

#220
post #139
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…

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

COM is kind of like GObject and something like it has a place.

COM usage is fairly limited because using it easily requires compiler support, which only very recently was included in the Community editions of Visual Studio. You can also access COM via language bindings; most .NET code you write is COM-enabled, for example, and is accessed from non-CLR code as COM. MinGW has stuff that lets you use and generate COM classes, but it's not great. Improving it would help FOSS dev on Windows.

There are other languages that use COM also. The lead designer of Delphi was poached by Microsoft to design .NET.

Post reply on HN