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

201–210 of 317 posts

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

#201

Post by pjmlp »

zerkten wrote: post #175
pjmlp wrote: post #132

Earlier quoted context omitted.

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

I think Sinofsky was still in Office when this was happening. He comes into the picture with Windows 8 since Microsoft wanted Windows to be as successful as Office had become. Jim Allchin ( https://en.wikipedia.org/wiki/Jim_Allchin ) was in charge at the time of Vista. Office had stuck with regular the regular Windows platform and were focusing on UI and getting into a regular release rhythm under Sinofsky. People fo…

Thanks for the correction regarding Sinofsky .

Undoubtedly there were multiple issues at play there.

However having been part of such "rebuilt the world" projects, I do believe politics also played an important role, as many signs that came into the outside world feel similar.

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

#202

Post by teddyuk »

shawnz wrote: post #199
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…

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.

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

#203

Post by teddyuk »

zerkten wrote: post #175
pjmlp wrote: post #132

Earlier quoted context omitted.

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

I think Sinofsky was still in Office when this was happening. He comes into the picture with Windows 8 since Microsoft wanted Windows to be as successful as Office had become. Jim Allchin ( https://en.wikipedia.org/wiki/Jim_Allchin ) was in charge at the time of Vista. Office had stuck with regular the regular Windows platform and were focusing on UI and getting into a regular release rhythm under Sinofsky. People fo…

I'm not sure that is right, Sinofsky was brought in to fix windows dev after the vista fiasco, he did a good job on win 7 then went off piste with the metro ui in win 8 and that was it for him

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

#204

Post by SideburnsOfDoom »

jeswin wrote: post #105
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…

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

> No not dynamic

Ok, I see that structural typing is a third type system option.

But honestly, I don't want C# and .NET to contain every feature and paradigm ever created. It would be bloated and hard to use. Already there is significant legacy and different ways of doing the same thing, and it's likely to get even worse.

If the language that you ideally want is built around structurally typed free-floating functions, then it probably isn't C#. It probably exists, it's likely possible on the .NET platform, but it doesn't work and think like C#.

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

#205

Post by Volrath89 »

merb wrote: 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.)

Have you tried itextsharp? https://www.nuget.org/packages/iTextSharp/5.5.13.1

I've successfully used it both in .net 4.7 and .net core 2.2 to generate complex pdf structures, and it has been a great experience.

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

#206

Post by noderat »

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

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

I really wish the documentation for things like DI, IOptions and ILogger were moved out of the ASP.NET documentation. Trying to decipher from the documentation how to use these in a non-ASP.NET project is needlessly complicated.

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

#207

Post by moron4hire »

LandR wrote: 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 Standard 2 relaxed the versioning requirements that led to so many binding redirects.

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

#208

Post by Topgamer7 »

enlyth wrote: post #56
mariusmg wrote: post #19

Earlier quoted context omitted.

>Btw, Linux as a deployment platform works quite well. What are you using in production for Linux ? Kestrel + Nginx ? Any problems encountered with this setup ?

I am using nginx as a reverse proxy to kestrel in production on one of my projects and it seems to be working great so far

Yeah I do the same, lets me do seamless deploys. I spin up the new version, change the nginx config, then tear down the old one.

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

#209

Post by Volrath89 »

pts_ wrote: post #33

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

.NET is an enterprise framework, mostly used in B2B software, which is rarely "rockstar"

Anyway, who cares about it, when the bulk of job vacancies are offered by the enterprise. It's a lot easier to find a junior dev role for a .NET dev than for a Ruby dev for example: https://www.youtube.com/watch?v=ZUgNy-okDQ4

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

#210

Post by teddyuk »

thrower123 wrote: post #194
pjmlp wrote: post #43

Earlier quoted context omitted.

Including resource usage! As anything on top of InteliJ.

One of the nice things about Rider, though, as opposed to ReSharper, is that it can be run as 64-bit, and you can control the size of the Java memory heap, rather than being jailed inside the 32-bit devenv.exe process. Visual Studio with Resharper chokes and dies pretty badly when you get into large solutions with 100k+ LOC and many projects. For years I've been seeing problems when memory usage gets close to 2GB, an…

something I have noticed with vs 2019 is that it creates lots of processed, presumably to try and give itself more than a single 32-bit address space
Post reply on HN