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

281–290 of 317 posts

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

#281

Post by merb »

e12e wrote: post #262
merb wrote: post #147

Earlier quoted context omitted.

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…

I never said that I can't sell AGPL software. just that I can't use AGPL in a closed source project.

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

#282

Post by merb »

manigandham wrote: post #130
Dolores12 wrote: post #86

Earlier quoted context omitted.

No, i just didn't like the wording in the original post mentioning all 'modern workloads' , while ubiquitous thing like cookies in httpclient is still not according to 8 year old standard. Does it make any sense now?

Modern workloads refers to the kind of applications commonly built today, like http/json/grpc webservices running in containers. And yes the HttpClient is modern. Your entire argument so far has been a single RFC issue that is labeled up-for-grabs because it's so minor and doesn't really affect anyone. Claiming the http functionality and the whole stack isn't modern because of it just doesn't add up.

especially since cookiejar is kinda useless. you can't use it with more than a single server, anyway..

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

#283

Post by manigandham »

deskamess wrote: post #278
manigandham wrote: post #71

Earlier quoted context omitted.

We run Kestrel directly facing the internet serving http2 traffic across billions of requests per day with no issue. No need for Nginx.

Which Linux distro are you going with? Any recommendations for/against distributions.

We deploy our apps as containers on top of the standard dotnet images: https://hub.docker.com/_/microsoft-dotnet-core-aspnet/

The default uses debian but they have ubuntu and alpine variants too. We stick with the defaults and don't have any preference for distro.

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

#284

Post by manigandham »

pknopf wrote: post #258

You know what's funny? ASP.NET Core 2 previews dropped full framework. The community freaked out, warning of a Python 2/3 split, and Microsoft backtracked. Fast forward to 3.0, Microsoft did it again, and nobody seems to care.

True, it's another lesson in change management and perceptions. Looks like people have finally figured out .NET Core is the clear future and it's about time to move on from the legacy framework.

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

#285

Post by wokwokwok »

manigandham wrote: post #276
wokwokwok wrote: post #92

Earlier quoted context omitted.

Oh no, don’t do that. The vscode integration is barely beyond autocomplete, and it uses more memory than rider does. The c# story for vscode still has a long way to go before it’s even close to feature parity. (...and yes, if you scrabble enough plugins you can get more features, but you get more crashes and even more memory slurping. :/)

What do you mean? The official C# support is from the Omnisharp plugin [1]. Omnisharp is the official .NET cross-platform development support system and is used across many different interfaces (VSCode, Atom, Sublime, etc). It's powered by Roslyn [2], the C# compiler platform, and can use the same packages for analyzers and autofixes that VS uses. It also has official debugging support. This is way beyond autocomplet…

I don’t know what to say; except, yes, and the experience on atom, sublime and the other tools that use omnisharp is terrible.

It’s not unusable, but for example, I can’t refactor my code base without it crashing, and forget any advanced features like jump to symbol or extract class. The only feature that works reliably for me is autocomplete.

I can only speak for personal experience; omnisharp on Windows and Mac, on .net core (or heaven forbid you use something non standard like unity3d) ...

It’s just terrible.

Perhaps your combination of platform / project is a different story, but I try it again every few months, and bluntly, rider is just better at everything.

Visual studio on windows is also excellent, and the tooling is usually tighter (rider usually lags when new stuff like .net core 3 comes out, and the azure function integration is a bit spotty because it uses the core tools).

/shrug

Tldr; my experience, on multiple platforms on multiple projects has been simply negative every time I’ve used it.

Ymmv.

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

#286

Post by supernovae »

tonyedgecombe wrote: post #120
gnud wrote: post #41

Earlier quoted context omitted.

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.

Not only that but the new interface is becoming just as complex as the old. By the time they have finished they will be back where they started.

Nah, it's pretty simple these days and people who love scripting can use powershell for everything

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

#287

Post by caseymarquis »

sword_smith wrote: post #67
manigandham wrote: post #23

Earlier quoted context omitted.

Are you making interfaces for everything? Just register and use the class with constructor injection. All those layers of indirection just waste time. What would change with functions outside of classes? You already have anonymous functions/lambdas, static classes and extension methods if it's about instantiation overhead, and local (nested) functions. Can you explain a scenario where this doesn't work for you? For n…

It would seem to me that you wouldn't be able to mock all the classes if you followed this strategy.

I'm pretty sure you could do this via reflection and virtual public methods. The same way entity framework creates its proxy classes.

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

#288

Post by kgwxd »

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.)

I'm going to need this very soon (not PDF/A 3 specifically, just PDF). A few months ago I did some research and I figure Skia[1](Sharp)[2] would end up being the base for any .NET core PDF libs. At the time, I was easily able to make a basic functioning demo for a project that ended up dying. Anyone using it in production?

[1]https://skia.org/user/sample/pdf [2]https://github.com/mono/SkiaSharp/

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

#289

Post by pjmlp »

snagglegaggle wrote: post #242
pjmlp wrote: post #226

Earlier quoted context omitted.

Anders went to Microsoft to design J++. .NET only came up a couple of years later and as follow up on Sun's lawsuit. Ext-VOS design document clearly refers to Java and J++. Secondly, I have been developing for Windows since Windows 3.0 and wonder which compiler support features do you mean. Even the old express editions had the required Windows SDK tooling for COM.

No, guy I'm thinking of was hired on about the time .NET was being started. This was after Borland. The tools may have just been for COM object generation. I found the option to generate COM code in VS2017 one day, followed up on it, and found it was the first time they had been released. The bare headers were always there but the code generators were not, at least in most current releases.

It was certainly Anders, no idea about whom you are talking about.

https://www.welcometothejungle.co/en/articles/anders-hejlsbe...

Again, I never had to enable anything on VS to generate COM components.

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

#290

Post by jayd16 »

bob1029 wrote: post #271
jayd16 wrote: post #46

Earlier quoted context omitted.

We're using it for a game server that interfaces with a Unity client. Works damn well. As someone who makes games, that's a standard business application for me, but YMMV.

Have you run into any difficulties with the GC, or are you already playing around with some of the configuration options here?

No issues but the use case is an internet hosted dedicated server so as far as the client is concerned network variance mask any GC concerns.
Post reply on HN