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

261–270 of 317 posts

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

#261

Post by LeonB »

contravariant wrote: post #143
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 find structural typing is mostly necessary when someone messed up and used a class where an interface should have been used. I'm now currently in the position of having to decide whether it's better to accept defeat or use T4 or similar to write the 1000+ line wrapper class to undo the mistake... You'd think Microsoft would at least remember to do dependency inversion through interfaces in their own C# code.

I wrote a tool, NimbleText which is free and good and lightweight for these one off 1000-line code generation scenarios. See https://nimbletext.com/live or email me for help (support at nimbletext)

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

#262

Post by e12e »

merb wrote: post #147
morrbo wrote: post #141

Earlier quoted context omitted.

I've extensively used itext with no issues on core

itext is extremly overpriced. btw. you can't use the AGPL version in any closed source project.

This is one of those cases where distribution really matters; for quite a lot of the work we do, AGPL would probably be fine (to-order in-house business tools;client pays for development, gets source anyway).

While selling those tools under AGPL certainly would be both Free and open source (but not gratis!) - the only real impact of the AGPL would be on our client - in that they'd be guaranteed the four freedoms (but they generally specify that in the contract anyway - they want the possibility to continue development in house, or with a possible new partner down the road).

However, the products are proprietary in the sense that our client only ever use then in-house and don't distribute them or expose them as public facing services. So no redistribution.

So you're technically correct (the best kind of correct!) - I just think the distinction is important, as you certainly could sell software with AGPL components.

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

#263

Post by WorldMaker »

Rapzid wrote: post #224

It would be great if app domains or some other form of sandboxing came back? Perhaps with faster communication between domains..

Depending on your needs, of course, AssemblyLoadContext supports unloading, if the goal is simply loading then unloading plugins.

(Security sandboxing is obviously a different matter, but Microsoft hasn't seemed too keen on the old .NET 1.0 CAS model for over a decade now, and has mostly recommended against it.)

Example code: https://github.com/dotnet/samples/tree/master/core/tutorials...

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

#264

Post by WorldMaker »

privateSFacct wrote: post #179
scott00 wrote: post #166

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.

> I thought WPF / Core was the recommended / modern approach.

The recommended / modern approach for 100% new applications would probably still be UWP (WinRT XAML) / Core, except getting that up-to-date with the latest .NET Core improvements is currently delayed until .NET 5.

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

#265

Post by WorldMaker »

mumblemumble wrote: post #193
thrower123 wrote: post #188

While I'm happy to hear this on one level, as it likely means that .NET Core is finally going to be approaching some levels of stability that allow it to be used in earnest for production usage, I'm somewhat dismayed. There's still a lot of things missing from it that the 4.X full framework version had, and this feels like it is the door slamming shut on hopes that existing code could be seamlessly upgraded without a…

FWIW, the decisions on what not to port that I'm aware of seem to make sense. WCF, for example: Its a legacy technology that is also horribly complex and never really took off. It was never really a good solution if you wanted cross-platform RPC, and therefore has a userbase that doesn't overlap much with the people they're trying to attract with .NET Core. If you're trying to migrate to .NET Core in order to go cros…

Worse than that, too, was that WCF tried to be an "all worlds" solution, so it was an okay-not-great RPC toolkit, and an okay-not-great REST API toolkit, and an okay-not-great IPC toolkit, (and it tried to be a terrible P2P communications toolkit for several years), and so forth.

Replacing WCF won't be easy in a lot of cases not so much because there's a lot of WCF-specific code, but simply figuring out where on the flowchart of possible concerns to migrate to:

Were you using WCF for RPC? Try gRPC, unless you really need SOAP support or worse WS-* support (I'm sorry) and then, uh, good luck. (Though SOAP libraries for .NET Core do exist and turn up in search results, depending of course how far down the WS-* rabbit hole you need to go.)

Were you using WCF for REST API? Try ASP.NET directly now instead of indirectly. Need client tools support? Take a look at Swagger (now aka OpenAPI) to replace WCF's odd extensions to SOAP's WSDL for REST APIs. Or maybe look into GraphQL (or less commonly Falcor) if you want something really new and wild.

(Were you using WCF for P2P communications? That hasn't been officially supported since Vista and whoops.)

WCF was actually pretty well built for exactly this sort of migration (the focus on interface-first design, data contracts, etc; in some cases it's just writing interface implementations where there were none before), and even the most WCF heavy applications were far more about fiddly giant bits of config files than actual code specific to supporting WCF. I really do think that half the challenge in migrating away from WCF has more to do with figuring out which tool (or tools, given you might have been using WCF for multiple things) to migrate to, as much as any actual code migration.

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

#266

Post by AbortedLaunch »

wlesieutre wrote: post #238
DennisP wrote: post #178

Earlier quoted context omitted.

I've got a Macbook Pro and it doesn't seem to have or need this feature in the first place.

It does have an analogous feature, the MBP's trackpad is huge and you probably touch it by accident all the time. It's just that Apple's system tries to separate deliberate touches from accidental ones, rather than disabling the trackpad input completely. You used to be able to turn this on and off (it was called "Ignore accidental trackpad input" in the trackpad preference pane) but now it's an always on feature. Th…

It may work quite often without me knowing, but ever since I got a 2017 Mac I have multiple events per day where my typing ends up in a random location due to phantom clicks. Perhaps I should disable tap to click, even though I really dislike clicking via the force push.

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

#267

Post by the_pwner224 »

DennisP wrote: post #254
wlesieutre wrote: post #238

Earlier quoted context omitted.

It does have an analogous feature, the MBP's trackpad is huge and you probably touch it by accident all the time. It's just that Apple's system tries to separate deliberate touches from accidental ones, rather than disabling the trackpad input completely. You used to be able to turn this on and off (it was called "Ignore accidental trackpad input" in the trackpad preference pane) but now it's an always on feature. Th…

Yes, I touch the pad by accident all the time. But why is Apple so good at detecting which touches are accidental, while so many other manufacturers are not?

On Linux this works similarly. ~5 years ago my old laptops did the 'disable touchpad when typing' thing, now with libinput the touchpad has excellent and completely invisible (to the user) anti-false-touch functionality.

Apple has invested the time to make great trackpad drivers. People have invested time to make libinput a great driver for Linux (in this regard - it does lack customization possible in older drivers).

On Windows the manufacturers don't care. IIRC MS is doing a thing where manufacturers can add some property to their touchpad HW/drivers which tells Windows to handle the touchpad entirely on its own, and the result has been that touchpads have been improving significantly over the last few years since MS is investing time in making good drivers. But that depends on your specific touchpad allowing Windows to do its magic, instead of using crappy OEM drivers.

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

#268

Post by 1wd »

scott00 wrote: post #197
privateSFacct wrote: post #179

Earlier quoted context omitted.

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.

Yeah, I think the Microsoft messaging would naturally lead you to that conclusion, though generally they avoid saying it explicitly. I think in a year WPF and WinForms will probably work great under .NET Core, but I wouldn't use either for real work right now. My recommendation would be to use .NET Framework for GUI work right now, but do it in such a way that the upgrade path is easy. The way to do that is to create…

Can you put WPF code in .NET Standard 2.0 libraries somehow?

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

#269

Post by [deleted] »

WorldMaker wrote: post #245
fauigerzigerk wrote: post #59

Earlier quoted context omitted.

One of the key problems of our time (besides antibiotics resistance, climate change, lack of affordable housing, poverty, rise of nationalism and totalitarian ideologies, mass surveillance, etc) seems to be the impossibility of reliably generating reference counted code from code written for a tracing GC.

But why should reference counting code be the "default" over a tracing GC in the first place? If the "problem" is embedding tracing GC inside of reference counted worlds, but tracing GC itself has little to no problem embedding reference counted worlds, why not invert the stack? Lisp machines in the 60s were doing tracing GC in hardware. It's not like we don't have the technology to move tracing GCs further down the…

[deleted]

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

#270

Post by bob1029 »

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 went from NetFramework->NetCore 2.x->NetCore 3.x with very few difficulties. The hardest phase was NetFramework->NetCore 2.x because of the differences in dependency resolution rules (e.g. no binding redirects allowed).

We ultimately restructured our projects a bit to dramatically simplify the number of points of touch for managing 3rd party nuget versions. We now have a common platform core (targeting NetStandard 2.1), with specific application implementations consuming it and targeting NetCore 3.0. Mercifully, we were able to capture 100% of our 3rd party dependencies into this common platform core project, so we no longer have to worry about mismatches between our own internal projects or nugets. The picture for us is: (3rd party libs)=>(shared platform library)=>(specific application). This seems to work out really well, and with the newer AOT/linker capabilities, we are resting easier knowing that we can shake off some unused bytes if our distributions start getting a little chunky due to this approach.

Also, the .NET compatibility pack is a life-saver for anyone stuck using System.Drawing or DirectoryServices. Those are our only 'difficult' windows dependencies, and we expect to be able to replace these with cross-platform alternatives next year.

Post reply on HN