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

161–170 of 317 posts

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

#161

Post by platz »

dvfjsdhgfv wrote: post #119
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 can sum up the situation with two sentences: I hate writing Win32 apps, but I love using them. I love writing .NET apps but I hate using them. The problem with Win32 apps is that although they look ugly, in general they're blazing fast and work basically everywhere. The problem with .NET apps is although they're aesthetically pleasing, they require the relevant version of the framework to be installed. I remember f…

Core apps can be deployed standalone

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

#162

Post by moron4hire »

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…

You can get most of the way to functions outside of a class with "using static". I often do "using static System.Math;" to have bare may functions. Also often do the same with System.Console.

I'm not sure what your thoughts are on Structural Typing, but I've found liberal use of extension methods on interfaces to be a really useful way to get lots of functionality on a wide variety of types.

As for your comment on namespaces, I cannot agree. Again extension methods would not be anywhere near as useful if one can't arbitrarily add code to any namespace, without needing to adhere to a file system structure.

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

#163

Post by shhsshs »

thomasz wrote: post #160
jeswin wrote: post #72

Earlier quoted context omitted.

> Then with static using directives, you don't need to spell out the namespaces. Static using directives! Certainly a useful tool, thank you. I had been away from the .Net universe for a while and I think I have some more catching up to do. Some of the newer changes in C# help a lot with reducing code heft, even though it makes the language more complex. However, the Framework seems to be headed in the opposite direc…

The asp configuration thing is complicated but powerful. If you don't want that, you can just use ``Environment.GetEnvironmentVariable`` and be done with it.

Plus it’s barely any extra work to load settings from environment variables. And it lets you write code agnostic to where the settings are coming from, and then choose to load them from environment variables, a file, hard coded values, etc.

Makes testing easier too because you don’t have to write a fixture around your settings. Just build the class with known setting values without writing code purely for testing.

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

#164

Post by UglyToad »

SamuelAdams wrote: post #157
UglyToad wrote: post #146

Earlier quoted context omitted.

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…

In the past I have frequently needed to merge several existing PDF's together. The idea is this: we have a list of objects Foo in a grid that is available to an end user. Each Foo item has a PDF that can be printed - some of our users really like to just look at the paper print out of everything. So we created a "bulk print" option. They tick a bunch of checkboxes for the Foo items, then click the Print button. Inter…

A large chunk of PdfPig started as a port of PdfBox (Java) , so it might be worth considering containerising or in some other way wrapping the PdfBox functionality to get Apache 2 licensed PDF merging [0] if this works for your scenario.

It's useful to know that this is a real use case too, I always assumed it was implemented 'just because' but the scenario you describe makes sense.

[0]: https://pdfbox.apache.org/docs/2.0.1/javadocs/org/apache/pdf...

Edit: another option is this pdfium wrapper for NET Core though it merges one pair at a time: https://github.com/GowenGit/docnet

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

#165

Post by moron4hire »

goto11 wrote: post #108
SideburnsOfDoom wrote: post #75

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…

Structural typing is different from dynamic typing. C# supports structural typing in the form of tuples and anonymous types. But you can't return an anonymous type from a method. This is a significant limitation. As for "free" functions: C# already recognizes the usefulness of this in the "using static" directive. This is useful for a lot more than "hello world".

You can't return an anonymous type, but the syntactic difference between an anon type and a tuple is two characters: parens instead of curly braces.

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

#166

Post by scott00 »

privateSFacct wrote: post #159

Question: I haven’t tried building a windows app in 10 years. That said, in the past I found it darn easy to wire an interface up quickly. I recently downloaded visual studio and could not quickly figure out how to get a GUI going (design view would not show). What is the recommended approach with this new stuff? Some buttons and textboxes on a form with an onChange method and a data bound grid? This used to be prett…

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 great experience though.

[0] https://developercommunity.visualstudio.com/content/problem/...

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

#167

Post by gameswithgo »

dvfjsdhgfv wrote: post #119
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 can sum up the situation with two sentences: I hate writing Win32 apps, but I love using them. I love writing .NET apps but I hate using them. The problem with Win32 apps is that although they look ugly, in general they're blazing fast and work basically everywhere. The problem with .NET apps is although they're aesthetically pleasing, they require the relevant version of the framework to be installed. I remember f…

With .NET Core 3, you can deploy them standalone, and performance is much improved. So you might have a happy middle ground available now.

And when I say performance is improved, there are two fronts to that. First, the compiler/jit are just better now, core library functions are sped up a ton, so just running ported old .NET Framework code will be a lot faster. But also, C# has added new features in recent years that give you further control over memory usage/layout, and now even SIMD Intrinsics, so the performance ceiling is much higher if you want to optimize your own code.

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

#168

Post by gameswithgo »

jeswin wrote: post #93
FpUser wrote: post #80

Earlier quoted context omitted.

What's the problem asking experienced developer to learn F#? That is course assuming they do not refuse the work?

Team dynamics in large companies can be quite challenging. In addition, whoever made that decision might become responsible for project delays, inability to hire, people writing bad code, destroying work-life balance etc. And not just you, everyone up the chain will get blamed for choosing a programming language with a near-zero market share. Generally large companies and enterprises are resistant to change, and my a…

At Olo, which is primarily a C# shop, people have been excited to learn F#, and able to pick it up on an as needed basis. We are pretty large and it has been fine. It helps quite a bit that it is a different language but part of the same ecosystem. It is quite a bit easier to manage than it would be adding say, Go, or Rust or something into the company, with entirely new tooling and libraries. for instance a visual studio solution can contain C# and F# projects, and they can refer to each other.

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

#169

Post by gameswithgo »

Digit-Al wrote: post #84
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 don't believe you will ever get functions outside of classes in C#. It is antithetical to the entire ethos of the environment.

you can just make a public static class FUNCTIONS and then use a static use at the top of each file, then pretend.

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

#170

Post by rafaelvasco »

jayd16 wrote: post #35
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…

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;
Post reply on HN