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

Understanding the .NET ecosystem: The evolution of .NET into .NET 7

andrewlock.net

Post reply on HN
Print view View original

341–350 of 357 posts

Re: Understanding the .NET ecosystem: The evolution of .NET into .NET 7

#341

Post by dingi »

moonchrome wrote: post #290
dingi wrote: post #274

Earlier quoted context omitted.

Except botched C# style rules. Rider still insists on Java style guidelines for .net projects. And sometimes, it spawns a never ending background process that only way to get rid of is to restart the app. Otherwise, it's okay. edit: been using Rider on Linux since a few years now

I've been using Rider style rules for two years now exclusively in a VS based team and aside from some linebreak rules I need to tweak here and there I've seen no issues ? But I use a .editorconfig tuned stylecop and roslynator on all projects so maybe that overrides some defaults. Mind sharing which Java style rules are you seeing ?

Rider highlights pascal cased class methods/attributes and suggests to use camel case, for example. I haven't changed any style settings. This is Rider default. Maybe its a Linux thing.

Re: Understanding the .NET ecosystem: The evolution of .NET into .NET 7

#342

Post by banashark »

bottlepalm wrote: post #336
banashark wrote: post #321

Earlier quoted context omitted.

Well you put a fairly normal select query there, which is can be accomplished in Lucid as well. Additionally change tracking exists since it's an ActiveRecord implementation. It's not all magic as well. Looking into the internals of EF, ActiveRecord, Hibernate, or other ORMs reveal patterns that once familiarized can help reason about the behavior of complex queries. I only state this to try to work against the commo…

Query builders are a thin wrapper on raw sql. Real ORMs that understand the relations between objects are not. There are a ton of joins and sub-selects in that query. 8 very succinct lines. Can you do anything close in Lucid? I don't think so.

Well I've put sources and links to multiple pages about the ActiveRecord implementation. The Lucid documentation for the ORM "query building" (which it's the same in EF, LINQ has "Integrated Query" in the name) does track entities and subentities, which is how you can query things update them, then later call `.save()` to persist them back to the database.

However, you seem set on making this a combative conversation rather than a collaborative discussion, so I'll end my participation here.

Re: Understanding the .NET ecosystem: The evolution of .NET into .NET 7

#343

Post by pjmlp »

Loocid wrote: post #338
pjmlp wrote: post #301

Earlier quoted context omitted.

Full stack Windows development, across all Microsoft products and various kinds of Windows SDKs, GPU debugging, hot code reload for .NET and C++, visual tooling for architecture workflows.

Rider does full stack (eg MAUI, Blazor, WPF, Xamarin etc for frontends and can publish to various cloud services) and has hot reload. What Microsoft products and SDKs does Rider not support? As far as I can tell GPU debugging is C++ only, where I thought we were discussing C#, same with the C++ hot reload. However CLion does both.

SharePoint, Dynamics, SQL Server SP in .NET, Sitecore (not MS but big player in enterprise CMS), 3rd party component libraries for VS designers, WDK, integration with Azure DevOps workflows, two way modeling of code (not on professsional), mixed language debugging, REPL for all languages, graphical tooling for parallel debugging, ETW, DockerDesktop replacement GUI, ...

We where discussing what a Visual Studio full install offers, with a single license.

Re: Understanding the .NET ecosystem: The evolution of .NET into .NET 7

#344

Post by sebazzz »

jiggawatts wrote: post #333
sebazzz wrote: post #312

Earlier quoted context omitted.

.NET Framework will be supported for much longer than that. It is used in many internal Windows components including MMC snap-ins, ADFS, and other Microsoft technologies like Exchange and Sharepoint. Or maybe it will not be supported as in "we won't provide support for any applications needing .NET Framework, but they may or may not still work"?

Or to phrase it another way: Microsoft themselves failed to migrate off .NET Framework to .NET Core for the same reasons their customers are also stuck. PowerShell Core has been available for years but still is not included with Windows. Similarly, even new web UI components such as Admin Center are written using .NET Framework.

> Microsoft themselves failed to migrate off .NET Framework to .NET Core for the same reasons their customers are also stuck.

I'd wager it is more a question of priorities. I bet Microsoft itself sees Windows Server as legacy tech as they want everyone to move to the(ir) cloud.

Partially it is also a organisational problem. Everything you ship as a Windows component incurs a debt, which is exactly why .NET Framework wasn't able to evolve further.

Re: Understanding the .NET ecosystem: The evolution of .NET into .NET 7

#345

Post by moonchrome »

dingi wrote: post #341
moonchrome wrote: post #290

Earlier quoted context omitted.

I've been using Rider style rules for two years now exclusively in a VS based team and aside from some linebreak rules I need to tweak here and there I've seen no issues ? But I use a .editorconfig tuned stylecop and roslynator on all projects so maybe that overrides some defaults. Mind sharing which Java style rules are you seeing ?

Rider highlights pascal cased class methods/attributes and suggests to use camel case, for example. I haven't changed any style settings. This is Rider default. Maybe its a Linux thing.

That's just a few .editorconfig lines away from begin consistent for the whole team.

Re: Understanding the .NET ecosystem: The evolution of .NET into .NET 7

#346

Post by Jochim »

smcl wrote: post #302
Jochim wrote: post #147

Earlier quoted context omitted.

The only frustration I've experienced in actually working with it is that it leads to polluted search results. Trying to find solutions to ASP.NET Framework problems usually requires discarding a whole bunch of irrelevant ASP.NET Core/.NET ones. It's the same with Visual Studio/Visual Studio Code.

It sounds like the issue you have is introducing breaking or backwards incompatible changes at all while retaining the a similar name. Which is a fair point. I’m not sure what would help in that case other than using something else than “.NET” to identify it.

Precisely. It's certainly not an issue exclusive to the .NET ecosystem but it is a minor annoyance in my day to day life. On the plus side it only affects work on legacy projects that haven't been migrated yet. One day will be the last day that someone needs to add "-Core", "-Code", "-.NET5", "+Framework" etc. to their search queries and that will be a happy day!

Griping about a minor inconvenience isn't to say that I don't think it was the correct decision. The new .NET is already far better than Framework, in how the platform is progressing and the development experience.

Re: Understanding the .NET ecosystem: The evolution of .NET into .NET 7

#347

Post by Jochim »

thenerdhead wrote: post #165
Jochim wrote: post #147

Earlier quoted context omitted.

The only frustration I've experienced in actually working with it is that it leads to polluted search results. Trying to find solutions to ASP.NET Framework problems usually requires discarding a whole bunch of irrelevant ASP.NET Core/.NET ones. It's the same with Visual Studio/Visual Studio Code.

This is a similar problem with ChatGPT and AI in general. While some things may not change much, you can't generally say "how do I x in .NET" without the chance of getting a really old answer.

Being more specific is definitely helpful. I've found that ChatGPT is less frustrating than DDG/Google, probably just due to the conversational nature. You can ask ChatGPT to correct itself if it doesn't give the answer you want. e.g. "Could you write that using .NET 7" or "Use to solve the problem".

Whether it spits out the correct answer is still up to chance but the narrowing does seem to work quite well.

Re: Understanding the .NET ecosystem: The evolution of .NET into .NET 7

#348

Post by Jochim »

WorldMaker wrote: post #329
Jochim wrote: post #147

Earlier quoted context omitted.

The only frustration I've experienced in actually working with it is that it leads to polluted search results. Trying to find solutions to ASP.NET Framework problems usually requires discarding a whole bunch of irrelevant ASP.NET Core/.NET ones. It's the same with Visual Studio/Visual Studio Code.

> Trying to find solutions to ASP.NET Framework problems usually requires discarding a whole bunch of irrelevant ASP.NET Core/.NET ones. My experience was this was always a problem even before later versions of ASP.NET. There was so much backwards incompatible changes between ASP.NET 3/4/5 and ASP.NET MVC 3/4/5 and even things that searching for ASP.NET MVC 3/4/5/6 would disagree with ASP.NET 3/4/5 non-MVC recommenda…

That's both reassuring and a bit depressing :P

I'm young enough to have only caught the tail end of Framework in my professional career but I do recall a lot of Razor Pages content showing up when looking for tutorials on MVC.

It's certainly not unique to .NET. Being stuck on an old version of Elasticsearch can turn into a nightmare when trying to find a quick a solution to a query problem.

Re: Understanding the .NET ecosystem: The evolution of .NET into .NET 7

#349

Post by bottlepalm »

banashark wrote: post #342
bottlepalm wrote: post #336

Earlier quoted context omitted.

Query builders are a thin wrapper on raw sql. Real ORMs that understand the relations between objects are not. There are a ton of joins and sub-selects in that query. 8 very succinct lines. Can you do anything close in Lucid? I don't think so.

Well I've put sources and links to multiple pages about the ActiveRecord implementation. The Lucid documentation for the ORM "query building" (which it's the same in EF, LINQ has "Integrated Query" in the name) does track entities and subentities, which is how you can query things update them, then later call `.save()` to persist them back to the database. However, you seem set on making this a combative conversation…

I had hoped you'd put some actual code in either of your last two replies.

Re: Understanding the .NET ecosystem: The evolution of .NET into .NET 7

#350

Post by WorldMaker »

drdaeman wrote: post #335
WorldMaker wrote: post #318

Earlier quoted context omitted.

WebApplicationBuilder itself is mostly the base .NET Generic Host [1] (which is "bare" .NET and is used as a common host for dependency injection plus common utilities such as configuration and logging) plus activating the Kestrel hooks for HTTP middleware. Kestrel even at its most "raw" is always slightly higher-level and closer to Flask or Express (JS) as a middleware-focused HTTP execution engine. (This partly ref…

Thank you very much for your comment! I don't have any issues with the IHost and builder patterns. I actually like those - although I've only used the very basics, so I don't really know about the intricacies and possible drawbacks. Thanks for clearing my misunderstanding about the coupling. I really thought Kestrel was something different, have not expected it to be this high level. It being a replacement of HTTP.sy…

There's an ancient historic low-level API, that I just remembered, which you can explore that still remains around for backwards compatibility but isn't recommended for new code: Kestrel was (via a long scenic route) forked from System.Net.HttpListener [1] which is the closest to a strict bare-bones HTTP.SYS wrapper that has existed in .NET.

There's a long issues thread on HttpListener should be more strongly marked deprecated [2] to avoid people accidentally using it despite today's recommendations to use Kestrel/the "Most Core" parts of ASP.NET. One fun part of the thread is an example repo of the absolute most "bare-bones" and "raw" Kestrel bootup possible [3], including a "TODO: implement TLS handshake here" bit.

[1] https://learn.microsoft.com/en-us/dotnet/api/system.net.http...

[2] https://github.com/dotnet/platform-compat/issues/88

[3] https://github.com/davidfowl/BasicKestrel/tree/master/BasicK...

Post reply on HN