Live data from Hacker News

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

andrewlock.net

181–190 of 357 posts

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

#181

I love the new dotnet ecosystem and use it professionally but am I the only one who thinks two years isn’t long enough for a “long term support” release? Obviously you’ll be able to run older versions of the framework so long as the underlying OS supports it but depending what type of environment you’re in this means you’re likely going to have to update perfectly working applications every two years. Do I think that…

>> 6 to 8

If you are using BinaryFormatter you certainly will have some work ahead of you.

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

#182

Earlier quoted context omitted.

Nextjs (and its contemporaries) work really well with .NET. Toss in your API calls into Next, write a beautiful front end, and now you've got separate front end and back end that works phenomenally together and can be tested separately using their strengths. I'm more shocked by you sticking with Javascript. Surely with your adoration of C# you would have moved to its closely related sibling Typescript. Although I gue…

> Nextjs (and its contemporaries) work really well with .NET. Toss in your API calls into Next, write a beautiful front end, and now you've got separate front end and back end that works phenomenally together and can be tested separately using their strengths. Is it somehow different than using any other language for your backend? Seems to me you're describing any frontend/backend split, nothing specific to either Ne…

Feel free to replace Next with another framework if that's more you're liking. Same benefits apply.

I'm not so sure experts of JS would avoid TS just because they're experts in JS. The opposite even, being experts they know how many footguns JS has, and TS just comes with far too many benefits for any project that is to be maintained for longer than a week.

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

#183
post #12

Been using .NET for years now for backend web development after having taken a break from C#. It is such an improvement over the old .NET framework. When I started building my first backend with it, I was surprised how much was included and "just worked". Need to add authentication? Few lines. OAuth? Also built in. Response caching? Yes. ORM? EF Core is pretty good. Need to use env variables to override your JSON con…

I'm definitely a fan of the "batteries included" approach, but I am ambivalent on EF because I feel like it is still a bit too magic and gets abused. Though it's not like it's a big deal to use whatever else you prefer instead (I am a big fan of the inline SQL with Dapper approach).

I stuck to DB-First model + LINQ + SaveChanges() and largely managed to keep out the magic quite successfully for a .NET6 web project last year. Records are fantastic when composing queries. I didn't touch inheritance or any fancy mapping strategies -- one table, one class.

The only bit of framework-specific / hidden magic debugging I really had to do was the realization of AsSplitQuery() when creating objects composed of independent datasets, AsNoTracking() for a decent perf bump, and single group-by's are fine but when you start nesting them it gets really hairy really quickly -- they usually ended up becoming views.

Otherwise change-tracking worked wonderfully for batch-updating (but everything I did was short-lived) and outside of group-bys, the LINQ -> SQL mapping (and vice-versa) was extremely predictable, in both EF Core generating the SQL I expected, and creating the correct LINQ from the SQL I knew I wanted.

9/10 would use again; inline sql is for nerds

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

#184
post #14

Earlier quoted context omitted.

It really is like finding enlightenment after having to figure out which third party package is best for every little thing in Node. Visual Studio is a pretty powerful IDE as well.

Jetbrains Rider is great for .NET too, although I didn't try backend developement with it.

I'm a web developer that has used VS Code for years, but these past few months have been using Rider for developing a Unity project. One thing that really stands out to me about Rider is the "Refactor" (Ctrl+Shift+R) feature; extremely useful.

It allows you to just build things rapidly without worrying much about patterns/naming because once your vague ideas solidify and you realize where you went wrong, it's really easy to just Ctrl+Shift+R and make any codebase-wide adjustments instantly.

It's also great about picking up sub-optimal implementations or patterns with helpful warnings, and you just Ctrl+. to have it auto-fix for you. Using these Rider features combined with Github Copilot, I was able to pretty easily learn intermediate level C# because it's like having a mentor working along side you.

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

#185

I love the new dotnet ecosystem and use it professionally but am I the only one who thinks two years isn’t long enough for a “long term support” release? Obviously you’ll be able to run older versions of the framework so long as the underlying OS supports it but depending what type of environment you’re in this means you’re likely going to have to update perfectly working applications every two years. Do I think that…

The upgrade process from 5 to 6 to 7 has been a total breeze, and I’expect things to continue in that matter. There was a massive amount of churn between the introduction of .NET Core and Core 3, then 3 to 5 was quite a bit less so, and since then it’s been a non-issue. Pretty much just flip a version flag and get new features.

> Pretty much just flip a version flag and get new features.

Sure, but in many cases for an application that is "done" we're not looking for new features, per se - we're looking for security patches. Moving from one major version to the next incurs a whole bunch of testing and validation that otherwise might not be needed (depending on your environment and industry).

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

#186
post #12

Been using .NET for years now for backend web development after having taken a break from C#. It is such an improvement over the old .NET framework. When I started building my first backend with it, I was surprised how much was included and "just worked". Need to add authentication? Few lines. OAuth? Also built in. Response caching? Yes. ORM? EF Core is pretty good. Need to use env variables to override your JSON con…

I have been having a ridiculous time trying to find out just how to override an appsettings json variable (DBConnection string) with an environment variable. Could not find any good answer. What is the right way?

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

#187

My big problem with .NET is that a lot of line-of-business apps were written using ASP.NET Web Forms, but there is no upgrade path other than “rewrite most of it”. It feels like the pain everyone went through upgrading from Python 2 to Python 3. It also doesn’t help that .NET Framework has its support cycle tied to the OS, and hence is 10+ years. This means that businesses can be lazy and just leave these old apps to…

The writing was on the wall a long, long time ago! These companies had 15 years to do it. And it was fairly easy to get webforms + MVC running side-by-side on the same site so you could gradually migrate. Too late for that now though, you can't run webforms + MVC Core side-by-side. You could put a load balancer in front of the old app and start moving end points to a new code base. It's akin to moaning that MS haven'…

> The writing was on the wall a long, long time ago!

The vast majority of ASP.NET Web Apps could not have migrated to .NET Core 1.0, it was missing too many features. It was missing types like 'securestring', and had zero support for Workflow Foundation, Windows Communication Foundation, etc...

At the time, .NET Core was also advertised as "an alternative platform for Linux apps", not as a direct replacement for .NET Framework.

It was only in .NET 5 that Microsoft changes their tune and started calling Core the "replacement". At the time, something like half of complex enterprise apps might be able to migrate across, but they would have encountered a long list of breaking issues with a note saying "we might fix that in an upcoming major release". That's after a partial rewrite.

You can't go to a business that has a web app that's "not broken" and suggest migrating it to a definitely broken platform that's very much still playing "catch up".

Support is improving in .NET 7, and the upcoming .NET 8, but it's definitely not 100% and pretending that it's the "end users' fault" for not jumping onto an incomplete and buggy platform is not helpful.

I'll list some random GitHub issues for you to perouse. For large enterprise apps, many of these are showstoppers for incremental or seamless migrations. The workaround is always "rewrite everything from scratch using wildly different technologies that aren't direct replacements."

    IIS app pool recycle throws 503 errors
    https://github.com/dotnet/aspnetcore/issues/41340

    OData core libraries now support OData v4 
    https://devblogs.microsoft.com/odata/announcement-odata-core-libraries-now-support-odata-v4/
    (.NET Framework is v1-v3, and Core is 4.0+, a breaking change!)

    Workflow Foundation didn't start getting migrated until .NET 6, and not by Microsoft!
    https://github.com/UiPath/corewf

    dotnet-svcutil ignores most of the settings
    https://github.com/dotnet/wcf/issues/4887

    dotnet-svcutil silently failing to deserialize responses
    https://github.com/dotnet/wcf/issues/4163

    Reuse of Types not working with WCF dotnet-svcutil tool for .NET Core
    https://github.com/dotnet/wcf/issues/4277

    Visual Studio 16.8 breaks SvcUtil build targets
    https://github.com/dotnet/wcf/issues/4431

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

#188

I spent a lot of time as a Java developer and have recently moved into a spot where I'm being asked to work with C#. A few things rub me the wrong way, and I'm wondering if it's just ignorance and / or me being stuck in my old ways. - Unit testing with mocking is kludgy compared to Java and Kotlin (Moq vs Mockito). There's no mocking of concrete implementations for technical reasons, perhaps unless you shell out mone…

> There is no mocking of concrete implementations

That's an obvious anti-pattern in the first place, especially when you know the optimizer could inline hot code and optimize the function out.

> Everything feels a lot more corporartized or tied to Microsoft

Remember J2EE and the confusing javax stuff? They're the same and fortunately both are waning out.

> The open source ecosystem and tooling around C# isn't to the same level of the JVM

Isn't that because of the open source community's refusal, rejection and resistance against Microsoft? Not only open sourcing is a first mover takes all, but specific to Microsoft they have been known to be hostile to open source in the past, most prominently one of the former CEOs of Microsoft blatantly called Linux cancer and what do we have today (https://www.theregister.com/2001/06/02/ballmer_linux_is_a_ca...)

Also, it is very well known Microsoft tried to spread FUD in the past in order to kill Netscape Navigator and tried to kill Java until it is almost being antitrusted to the extent of Baby Bells (https://en.wikipedia.org/wiki/Breakup_of_the_Bell_System?wpr...). Still Microsoft is not friendly nor hostile towards open source given that they let Mono lived, despite using Microsoft's trademarks and patents (you heard me right, dotnet has several patents and ECMA standards before!)

It's not like we dotnet people don't know the past shady shit of Microsoft, but I do believe in a convicted criminal could learn from the past, correct itself, move on from the past and be a better person off the record in the long run.

It's like a big bully tried to beat off a skinny nerd but now the nerd is as big as the bully now, and all of a sudden the bully found its conscience and begged for apology. It is natural for the nerd to not accept it in the first place. Except when both are nerds and the analogy may sound kinda odd.

But I also do understand not all people thinks like that especially for the open source community who is wary of Microsoft may attempt to commit a FUD to the open source community and they do have their memory and thus reactions, I don't have any means to control it. In fact most ordinary people would still choose to reject a convicted criminal in their community instead of accepting even if they have stopped the behavior, because it is a social stigma that indicates this person is of high risk

And contrary to Java world, the Oracle situation is getting more and more heated due to its predatory licensing agreement and people are flocking to other Java distributions. This could tear the Java ecosystem apart because it is the .NET Standard situation again and I'm pretty sure histories repeat. By the way, fragmentation is what ultimately killed MIPS and I think RISCV is on the watch.

Alas, time as always will tell, just like it's either hit or miss. We should look for a longer vision and see how it shaped out in the futures.

> The project structure feels odd

No it isn't. It's the multiprojects structure of Gradle, although I'm not sure if you ever heard of it in the first place given your reaction. In JS ecosystem this is aka monorepo but this means .NET Ecosystem actually have monorepos for almost the last two decades!

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

#189

I spent a lot of time as a Java developer and have recently moved into a spot where I'm being asked to work with C#. A few things rub me the wrong way, and I'm wondering if it's just ignorance and / or me being stuck in my old ways. - Unit testing with mocking is kludgy compared to Java and Kotlin (Moq vs Mockito). There's no mocking of concrete implementations for technical reasons, perhaps unless you shell out mone…

There are other libraries than Moq. Nsubstitute, FakeItEasy, etc. With Moq and most mocking libraries, you generally just need to make a method virtual for mocking concrete classes. Most mocking libraries use Castle Project's Dynamic Proxy, so they should be able to inject things without the need of interfaces. Interfaces for everything comes from the .net community's obsession with patterns, abstraction, clean archi…

Right, marking methods as virtual is the other route I saw. Are most C# codebases opting to do that rather than add interfaces? It feels weird to edit signatures like that for testability, but maybe it's just what I'm used to - I'm putting all of my objects in constructors already for testability's sake, and I'm no stranger to making a factory or two.

VSCode has been my way forward for file-based editing so far. It's not so bad - just feels like I'm doing things that I ought not to be when I'm searching for DLLs or a random "scripts" folder in the root folder of our repo in Rider. In IntelliJ IDEA, all of the folders are just sitting there, ready for quick edits.

I think C# overcommitted on interface-driven design. It's good in some instances, but the more I work in code the more I think that the majority of it is needless and oftentimes harmful to maintaining a healthy code base.

Thanks for the pointers! Nsubstitute looks cleaner than Moq at first glance.

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

#190

My big problem with .NET is that a lot of line-of-business apps were written using ASP.NET Web Forms, but there is no upgrade path other than “rewrite most of it”. It feels like the pain everyone went through upgrading from Python 2 to Python 3. It also doesn’t help that .NET Framework has its support cycle tied to the OS, and hence is 10+ years. This means that businesses can be lazy and just leave these old apps to…

ASP.NET Web Forms are a complete trainwreck and an abuse of HTTP and other basic web development standards (e.g. by using javascript: URLs and POSTing forms for every single interaction with the page). It is broken by design. ASP.NET MVC 1.0 came out in 2009, there was plenty of time to modernize those apps.

I'm not sure you're addressing anything the comment above said.

Their complaint was that people invested a lot of resources into a technology that Microsoft promoted, and then that technology hit a dead-end with no good upgrade path aside from "rewrite it all!" What year that occurred is irrelevant.

Ironically you brought up MVC 1.0, which Microsoft did EXACTLY THE SAME THING TO, when they released Asp.Net Core MVC which also has no direct upgrade path. In fact, it wasn't until the last twelve months that Microsoft even tried offering anything when they realized it has been ten years and a lot of companies remain stuck to this day on .Net Framework.

Yes, Web Forms was poorly designed. But this is about Microsoft's poor upgrade offerings more than any specific technology, and an import lesson for people investing time/resources into Blazor today (given that it uses a proprietary WebAssembly compilation system and a proprietary back-end not dissimilar from WebForms in terms of lock-in).

Post reply on HN