Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

.NET 5.0

devblogs.microsoft.com

Post reply on HN
Print view View original

361–370 of 466 posts

Re: .NET 5.0

#361

Post by scns »

reader_mode wrote: post #324
starik36 wrote: post #295

Earlier quoted context omitted.

I think the OP is referring to accessing the config 5 layers down from the controller. I've run into it myself. To be able to do that, you have to add Options to the constructor of every class in the chain and then configure DI for it. It just has bad code smell. On my last project, I just assigned the configs to a static class that's available everywhere and the code was just simply much cleaner.

Smells like you're not doing DI properly :)

Is it a bad design, if it could be held wrong?

Re: .NET 5.0

#362

Post by zvrba »

davidfowl wrote: post #346
0xcoffee wrote: post #216

Earlier quoted context omitted.

I am aware of this, but like many other, I find the IOptions a bad abstraction. This blog has similar thoughts: https://rimdev.io/strongly-typed-configuration-settings-in-a... or this blog: https://adamstorr.azurewebsites.net/blog/beyond-basics-aspne... Or simply google 'asp net strongly typed configuration' and notice everyone seems to be reaching similar conclusions and building their own things. Just load the sett…

Options are a very misunderstood abstraction that we have done a poor job explaining. Those blog posts are simplistic and don't explain what you gain and lose by using the options abstraction.

> that we have done a poor job explaining

Yes, indeed you have. I've tried to both skim and read the "introductory" documentation for `Options` and the only gain I could figure out is monitoring + refresh. I still have no idea how to use it though, so I don't.

Re: .NET 5.0

#363

Post by bruckie »

teh_klev wrote: post #319
qz2 wrote: post #42

Earlier quoted context omitted.

Exactly. Yes I interviewed at a company where Silverlight and WCF was the future and they'd just rewritten everything in it. I didn't see it with the way everything was going. I dread to think of what happened to their business when the rug was pulled out overnight. "Microsoft says you need to start funding your entire product to be rewritten from scratch"

I don't know how long ago you're speaking about, but Silverlight and Flash were at their end of days even back in ~2006. Apple just nailed the coffin shut. That's not Microsoft's fault, there was a sea change in the industry away from browser plugins and these types of platforms. Apropos WCF, well we got JSON and no-one outside of "enterprises" were doing SOAP/WSDL et al any more and it was pretty much done. That's n…

Silverlight wasn't even born until 2007, so it's hard to see how it was dead in 2006. :)

Or maybe you're saying it was DOA?

Re: .NET 5.0

#364

Post by hackerfromthefu »

ocdtrekkie wrote: post #267
huzaif wrote: post #230

Earlier quoted context omitted.

Publish your apps without .net core (--no-self-contained) and install/manage runtimes as you usually would. If you have thousand apps, you probably also have a CI/CD system and you can gain fine grained control on your runtime management needs with .net build/publish. MS does quite a few things poorly but they have done a solid job of operating in large enterprises.

"Publish your apps" isn't the issue: I support a lot of applications I don't build or have the source code for. And they may be on my network for over ten years. The problem is if developers are publishing self-contained apps with .NET Core, IT staff will be up a creek on vulnerability mitigation. While being able to pin specific .NET Core versions is nice for developers, being able to require the most current .NET C…

I'm expecting as this issue plays out, there will be a way to inject an updated framework to an existing app with a utility tool. Probably first party but definitely third party.

Re: .NET 5.0

#365

Post by reader_mode »

scns wrote: post #361
reader_mode wrote: post #324

Earlier quoted context omitted.

Smells like you're not doing DI properly :)

Is it a bad design, if it could be held wrong?

Well from the sound of it he's instantiating objects manually 5 levels deep and he has control over all those constructors since he passed a new parameter through all of them.

So it sounds like basically he's not using DI (is just using it to pass stuff to controllers) and is surprised that using a library designed around DI is awkward. The correct solution is use DI to construct that hierarchy and then you can just request IOptions at the bottom/where you need it.

Re: .NET 5.0

#366

Post by hackerfromthefu »

mmd45 wrote: post #10

the highlights are great. 2 lowlights: - HttpClient/WebRequest ReadWriteTimeout is silently ignored which can result in infinitely hung sockets when doing synchronous network i/o - System.Speech is unsupported

Ouch! HttpClient/WebRequest ReadWriteTimeout never timing out is going to affect a lot of systems and result in production issues.

Re: .NET 5.0

#367

Post by mjsabby »

dazbradbury wrote: post #317
flamtap wrote: post #287

Earlier quoted context omitted.

>I expect our migration from 3.1=>5.0 will be a total non-event, but we don't want to risk any regressions during our current crunch phase FWIW, I just did a find/replace across 66 projects for `netcoreapp3.1` => `net5.0` and it build and passed tests first try. There were a fair few new nullable reference type warnings though!

"Our migration from 4.7=>2.0 was the most difficult" Would love to see a write up of your challenges / approach. Seems to be a big lack of write ups on this process that I'm sure lots of devs would appreciate!

My team did this when we moved Bing.com over to .NET Core, but it's internal. I will see if we can make it public. The problem is there are some skeletons in the closest that are irrelevant now (some since NS2.0, more since netcoreapp3.1), so I wonder how informative it will be.

Re: .NET 5.0

#368

Post by MarkSweep »

the_arun wrote: post #13

I know .NET Core applications could run on Linux. But do they natively (without any wrappers) support Linux OR is there a wrapper to simulate windows within Linux?

The C# libraries either invoke the native Linux libraries directly or go throw a thin wrapper[1] that does the normal things you have to do to support multiple flavors of Unix (epoll vs kqueue, etc). Parts of the C++ runtime are written in terms of the Win32 API and on Unix these API are implemented in the PAL[2]. The PAL is not that big and I don’t the steady state performance critical code paths go through it.

1: https://github.com/dotnet/runtime/tree/master/src/libraries/...

2: https://github.com/dotnet/runtime/tree/master/src/coreclr/sr...

Re: .NET 5.0

#369

Post by ripley12 »

kqr wrote: post #360
_acco wrote: post #258

The future is very bright for .NET. It has the right raison d'etre - .NET is part of the growth story for Nadella-Microsoft. They already have you programming in their editors (VS/Code) and pushing to their VCS (Github). They're even teaching you the C# type system with TypeScript :) If they can just convince you to use their stack, Azure will win you over from AWS every time. As a result, I really wanted to adopt .N…

Yeah, this is a big problem. I wanted to understand the differences between just C#, F#, .NET Standard, .NET Framework, and .NET Core, and it took a somewhat long article[1] just to figure that out! [1]: .NET on Non-Windows Platforms, a Brief History. https://two-wrongs.com/dotnet-on-non-windows-platforms-brief...

...and if you’re creating a new class library today, you also need to understand how UWP and .NET 5 fit into the picture!

I’m not complaining too much, they are intentionally addressing this fragmentation, but it’s a real mess for newcomers.

Re: .NET 5.0

#370

Post by xpressvideoz »

It is a bit sad that so-called "native AOT" was not included in the release. When I heard last year that .NET 5 would support single-file binary, I expected it to be the same as something like Rust or Go would offer. But no, Microsoft changed the meaning of AOT and moved the goal post, introducing the real AOT as "native AOT". Thankfully they are aware of the issue, so I hope to finally see in when .NET 6, which will also be an LTS release, is released.

https://visualstudiomagazine.com/articles/2020/08/31/aot-sur...

Post reply on HN