Live data from Hacker News

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

github.com

181–190 of 317 posts

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

#181
post #35

Earlier quoted context omitted.

The closest you'll get to free floating functions are methods in a static class. The static classes essentially become namespaces. Then with static using directives, you don't need to spell out the namespaces. https://docs.microsoft.com/en-us/dotnet/csharp/language-refe... You can even put every global function into a single class but still organize your code across multiple files by making them all part of the same…

Don't get why people want floating functions. It makes easier to do bad coding and architecture imo. At least you must namespace them;

Consider something like the Math class. In practice it just works like a namespace for math-related functions. The only reason to have a class is because the language requires it.

It would certainly be cleaner without having to define a useless class.

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

#182

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.

I believe they did port IQueryable:

https://github.com/dotnet/corefx/blob/master/src/System.Linq...

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

#183
post #105

Earlier quoted context omitted.

> Allow functions outside of classes Why? You can put them in a static class, and if C# ever had this feature, it would just be syntactic sugar for a hidden static class. But that would mean optimising for "hello world" and other small script scenarios, which isn't a goal of the language design. > Adopt (files and dirs) instead of forcing namespace declarations Likewise. > Structural typing Like "dynamic" in C# 4 ? B…

> But that would mean optimising for "hello world" and other small script scenarios, which isn't a goal of the language design. Fairly complex programs can be written with just plain functions, all of them elegantly starting off column 0 instead of being tabbed for namespaces and classes. It works especially well with directory structure based namespaces. eg: Microsoft's own TypeScript. > Like "dynamic" in C# 4 ? No…

It sounds like you are using the wrong language. F# is what you want to be using.

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

#184
post #88

sadly .net core still lacks a good pdf library that is not priced over the top. (and at least supports building pdfs and creating pdf/a 3's.)

I'm currently building an open source (not copyleft) PDF library for.NET standard [0] and I'd be interested to hear more what you need on the document generation side. The current generation API for my library is extremely limited because I've never needed one but you are the perfect market research participant. It's an API I'm actively looking to improve. PDF/A compliance is probably quite a way off though. [0]: htt…

I have a .NET Core web app that needs PDF creation abilities. Can I be your market research participant as well?

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

#185
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 currently working on a social game app and proptech for a startup, both in .NET Core.

The game is Unity so C# on the app and .NET Core on the backend is nice to match up, common code.

The client on the proptech is Microsoft focused so they chose Azure/dotnet/C#/Xamarin.

Initially the proptech drawing/document app was on .NET Framework 4.6 and had the app running with Xamarin on Android + iOS when the app was to run on Android or iOS tablets/pads.

However, now the project uses Surface Books with touch/pen and Windows Ink so we went to .NET Core for UWP and that is the main app target now though it still runs on iOS/Android. Xamarin is quite nice for business apps that have to integrate to dotnet or any backend really. Lots of great developing and testing tools.

We have updated from .NET Core 1 to 2 to 2.1 and 2.2 and will be going to .NET Core 3 soon, by end of year.

The web app, apis and app are all .NET Core + Xamarin and it is nice. I have been doing .NET apps since 2000 along with Python, PHP and Node apps for interactive / promotional / game / drawing / rendering products and .NET Core is pretty clean and I love the nix implementations as well.

.NET Core 1 + updating to .NET Core 2 was a little rough reminiscent of the .NET 1.0 to .NET 1.1 and 2.0 initial start, lots of breaking changes, but .NET Core 3.0 is pretty solid and slowing down on massive changes, libraries and frameworks are almost all on it for what we use including IdentityServer4, SignalR, Xamarin (Standard) and more. The list of breaking changes is small this time [2].

There is the typical .NET base library depth that random deep errors you have to hunt down, and the thousands of libs/packages, but for the most part it has been not much more than speedbumps. .NET Core comes with lots of great security features for APIs/apps as well which helped us with compliance/security scans [1].

Now that .NET Core is pretty solid, and the linux/nix implementations and tools are far along, I expect with the ease of Azure, for Microsoft to really take some ground.

Microsoft ecosystem is a complete setup, from Visual Studio/Code to Azure to dotnet to Xamarin and UWP to Teams/Office and Surface Books with Windows Ink and even CI/github. They have retooled quite nicely, I left .NET in 2007-2010ish when developers took a backseat and they got it handed to them with mobile, but they are developer focused fully again.

Side note: I also love the Surface Book with the disconnecting screen and Windows Ink. My current machines are massive custom PC, massive Mac Pro (cheesegrater from 2013 that I love) and Macbook but seriously considering going Surface Book and probably just going to be updating/building on a Mac Mini for our Unity games instead of upping to the new cheese grater as it is the cost of a car or major home renovation project for the specs I want.

[1] https://docs.microsoft.com/en-us/aspnet/core/security/?view=...

[2] https://docs.microsoft.com/en-us/ef/core/what-is-new/ef-core...

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

#186
post #144

Earlier quoted context omitted.

It doesn't differ from that, but in languages that assume the presence of a tracing GC, that pattern is only used for resources other than memory. And therefore you can't (as far as I know anyway) compile arbitrary C#/Java/JavaScript libraries down to reference counted COM in order to make those libraries available to C++ or Rust code.

You can also use that pattern for memory management in .NET. For example stack allocations and unmanaged memory handles. .NET COM interop take care of exposing .NET classes to other COM aware languages. https://docs.microsoft.com/en-us/dotnet/standard/native-inte...

You can, but in order to translate arbitrary .NET code into reference counted COM you would need a guarantee that _all_ code is written like that or that you can statically infer the correct reference counting for _all_ code that isn't written like that.

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

#187

Can I use the occasion to recommend an VERY good book on modern C# programming: "Functional Programming in C#" by Enrico Buonnano: https://www.goodreads.com/book/show/31550964-functional-prog... I'm only a few chapters in, but already it has transformed my C#-writing in many ways, and I have ton of practical ideas on how to better structure my programs in a functional way as I go on.

The first half is an excellent book, buuuuut becareful as you get into the second half, it really becomes a book pimping his own library.

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

#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 lot of rework.

Time will tell how many existing libraries are fully ported to Core. For the foreseeable future, I expect that I'll still have to be working with the legacy framework, as there are so many SDKs that I require to interface with different products that will never receive the investment to bring them in line.

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

#189
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.

I really don't understand how you're having binding redirect issues with .NET core.

They're usually caused by a mixup between local packages and the GAC, which .NET core doesn't use.

When you publish a .NET core application, you can publish as stand alone and see right there in the publish directory all the DLLs that are being used.

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

#190
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.

> It means I know where the switches are, and more importantly, what they do

Does that mean you would never be comfortable with with a complete UI overhaul?

> The new UIs change with every minor update

I completely agree that this is a problem. And this part of my biggest issue with Windows 10. They're constantly reworking the new UI for what seems like micro-optimizations, but they're mostly ignoring the old UI. Not only is it a headache for users to keep up with new paradigms every 6 months, but there continues to be two areas in Windows to control system settings, one of which is hidden pretty well, and the location of settings between the two is continually changing. It's a nightmare.

.NET Core, on the other hand, is pure gold. It's fast, it runs everywhere, it's well document, and it's a joy to work with.

Which leads us to Visual Studio, which is becoming like Windows. Constant tweak updates that break things. I stopped installing '.0' releases, beacsue they're consistently broken.

Post reply on HN