Live data from Hacker News

Reinventing how .NET builds and ships (again)

devblogs.microsoft.com

81–90 of 146 posts

Re: Reinventing how .NET builds and ships (again)

#81
post #54
post #30

Earlier quoted context omitted.

My guess is if you build with .NET Framework you can just forever run your builds, but if your source code is based on newer .NET you have to update to a new version each year, and deal with all the work in upgrading your entire project, which also means everyone in your team is also upgrading their dev environment, and now you have new things in the language and the runtime to deal with, deprecation and all that. Pl…

Recent experience report: I updated four of my team's five owned microservices to .net 10 over the past two weeks. All were previously on .net 8 or 9. The update was smooth: for the .net 9 services, I only had to update our base container images and the csproj target frameworks. For the .net 8 services, I also had to update the Mvc.Testing reference in their integration tests. It's hard for me to imagine a version in…

I'm currently migrating dozens of projects to .NET 10. All of them so far were basically one line changes and a recompile.

You should be able to go from .NET 6->10 without almost any changes at all.

Re: Reinventing how .NET builds and ships (again)

#82
post #18

I have a lot of respect for the .NET team. They often publish great in-depth articles and their pursuit for performance is relentless (e.g. see Kestrel and Entity Framework evolution). And ASP.NET is one of the few large projects which managed to survive a large breaking changes. Almost to Python 2->3 level. You had to change how your web app behaved completely if you relied on their magic session which worked hard t…

Last time I tried Entity Framework it was slow. Replaced it with Dapper and a simple custom migration system. This took database validation and seeding from 10 seconds to less than 2 seconds during startup on low powered hardware with SQLite. The queries created by Entity had pointless cascade of multiple join statements. I have been reaching for GO with simple tooling and HTTP back end. .NET is useful for other solu…

We use newer Entity Framework (Core) in a few large projects with zero issues. Even have Dapper and moving away from it as it brings nothing to the table but strings and bunch of SQL.

Re: Reinventing how .NET builds and ships (again)

#83

Earlier quoted context omitted.

Not sure about the past tense here. .NET is still excellent and getting even better with every release. What instability are you talking about? There was the leap to .NET Core which was majorly breaking, but that was almost 10 years ago now.

If they’re in a team similar to some I’ve worked with, engineers are barely getting comfortable with the shift away from .NET Framework (!) There are legions of developers for whom Visual Studio on Windows is the only place they have ever been comfortable. And upgrading between versions of .NET is a point-click exercise between the various UIs (Visual Studio Installer, “Get New Components or Features”, and the NuGet…

You're totally right on all those changes, and I think all of those things were the bane of .NET development. Getting rid of all the cruft in one swift operation was life-changing. Finally being able to junk IIS and deploy web apps to Linux running their own tight little web server (Kestrel) is fantastic.

Re: Reinventing how .NET builds and ships (again)

#84
post #18

I have a lot of respect for the .NET team. They often publish great in-depth articles and their pursuit for performance is relentless (e.g. see Kestrel and Entity Framework evolution). And ASP.NET is one of the few large projects which managed to survive a large breaking changes. Almost to Python 2->3 level. You had to change how your web app behaved completely if you relied on their magic session which worked hard t…

I am not sure what the stats are but I am certain they left behind a huge number of projects. Probably a population that won't be very vocal on HN but that doesn't mean they don't exist.

Even for new projects there are problems I run into that force me to use 4.8. Like if you build an Excel formula, the mandatory async/await approach just doesn't work. It's not an asynchronous operation and runs into a UI context where you deadlock if you wait. They also broke a lot of the windows integration, where in a corporate environment the same network calls with the same syntax authenticate successfully with 4.8 but fail with core.

And because they broke backward compatibility on so many libraries, it's a non trivial effort to convert a complex code base to core.

It's great that they focus on performance, but the .net framework fossilised in term of functionality. It took like 15 years before they added a json serializer to the standard library, and don't even think about support for any new major image format (webp, heic). Everything has become complicated, there isn't a day where I don't see a crash message in visual studio. I used to be a big .net fan but I miss Anders' leadership.

Re: Reinventing how .NET builds and ships (again)

#85
post #18

I have a lot of respect for the .NET team. They often publish great in-depth articles and their pursuit for performance is relentless (e.g. see Kestrel and Entity Framework evolution). And ASP.NET is one of the few large projects which managed to survive a large breaking changes. Almost to Python 2->3 level. You had to change how your web app behaved completely if you relied on their magic session which worked hard t…

Last time I tried Entity Framework it was slow. Replaced it with Dapper and a simple custom migration system. This took database validation and seeding from 10 seconds to less than 2 seconds during startup on low powered hardware with SQLite. The queries created by Entity had pointless cascade of multiple join statements. I have been reaching for GO with simple tooling and HTTP back end. .NET is useful for other solu…

The trick with EF Core is to let it do the simple stuff and if you need anything more complicated than .Include write the query yourself.

Re: Reinventing how .NET builds and ships (again)

#86
post #61

I use c# also to earn my money. Sadly the new custom to hyperinflation in language sugar and framework makes following new things quite hard. Even today starting a new project I choose .net framework 3.5 and syntax. I know this sounds extreme but 3.5 has anything I need to build great software. It also offers a very tested environment. Setting up the software stack is a very easy process. Programmed following v2 runt…

Reminds me of an algorithms professor who'd get us to implement some modified standard algorithm in Java and then go over each implementation really quickly at the beginning of the next lecture. He'd find parts of your code weird, replace them really quickly and leave your clean, working implementation with 20 deprecation warnings.

At the end of the day both solutions/syntaxes work, but..

Re: Reinventing how .NET builds and ships (again)

#87

Earlier quoted context omitted.

Last time I tried Entity Framework it was slow. Replaced it with Dapper and a simple custom migration system. This took database validation and seeding from 10 seconds to less than 2 seconds during startup on low powered hardware with SQLite. The queries created by Entity had pointless cascade of multiple join statements. I have been reaching for GO with simple tooling and HTTP back end. .NET is useful for other solu…

We are also running into more and more performance issues with EF. There are ways to tune it but I am not sure if it’s worth learning this for EF or if it’s not better to just go for straight SQL. Seems MS has this tendency to create abstractions that then don’t work 100%. I see this with .NET too. Often you have to go down to Win32 for apps that are tightly coupled with Windows and hardware.

Are you talking about EF or EF Core? If the later, did you enable any or all of the magic like automatic property evaluation/eager fetching etc.?

EFCore by default is pretty performant - and pretty basic. You need to manually .Include() joins etc. which makes it pretty hard to become slow.

Re: Reinventing how .NET builds and ships (again)

#88
Modern .NET is awesome. In a small side hustle project, I develop a REST API Backend in C# on my macOS using VSCode, and deploy it to Linux for the past 3 years without any issues. I use SQLite, EFCore, Minimal APIs and it is a delight compared to the frontend part - which is NextJS/React/MaterialUI with 50+ (dev-)packages in npm.

Re: Reinventing how .NET builds and ships (again)

#89
post #73
post #49

Earlier quoted context omitted.

The only chaos occurred in the transition from .NET Framework to .NET (Core). Upgrading .NET versions is mostly painless now because the breaking changes tend to only affect very specific cases. Should take a few minutes to upgrade for most people.

Except it is a bummer when one happens to have such specific cases. It never takes a few minutes in big corp, everything has to be validated, the CI/CD pipelines updated, and now with .NET 10, IT has to clear permission to install VS 2026.

If you can't get permission to update/change IDE, the company processes aren't working at all tbh. Same if cicd is in another department that doesn't give a shit.

Re: Reinventing how .NET builds and ships (again)

#90
post #89
post #73

Earlier quoted context omitted.

Except it is a bummer when one happens to have such specific cases. It never takes a few minutes in big corp, everything has to be validated, the CI/CD pipelines updated, and now with .NET 10, IT has to clear permission to install VS 2026.

If you can't get permission to update/change IDE, the company processes aren't working at all tbh. Same if cicd is in another department that doesn't give a shit.

That is pretty standard in most Fortune 500, whose main business is not selling software, and most development is done via consulting agencies.

In many cases you get assigned virtual computers via Citrix/RDP/VNC, and there is a whole infra team responsible for handling tickets of the various contractors.

Post reply on HN