Reinventing how .NET builds and ships (again)

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

Last time I did excel interop it was COM based and there wasn't any async part of it. I'm curious if you were using COM interop also? Also, async/await was explicitly designed to work in UI contexts like Winforms and WPF where there is only a single UI thread...?

> It took like 15 years before they added a json serializer to the standard library..

That isn't really true. DataContractJsonSerializer [0] landed in .NET 3.5 which was in 2007. Admittedly, it kinda sucked but it was there and was usable. And also JSON.Net was around by that point and was/is excellent.

> ...and don't even think about support for any new major image format (webp, heic).

Image support on windows was historically provided by WIC [1] and does support the formats you talked about. But you are correct that native .NET support for many image formats is non-existent.

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

This is very true, and I felt it firsthand. My employer still has a codebase on .NET Framework (compiled against 4.5.2 but deployed against 4.8). It is WCF based and the jump to Core was a massive break. But in the end, I think the break was a good decision. There were just too many design mistakes, bad assumptions and underlying system changes to keep compat across the big leap to a modern multi-platform framework. .NET today is faster, more flexible and has more capabilities than .NET Framework ever did. Even if it did take a long time to get here.

And besides, even if new features are not coming to .NET Framework anymore, Microsoft has support .NET 3.5.1 until 2029! [2] Isn't 22 years of support enough? (.NET 4.8's EOL hasn't even been announced yet!)

[0] https://learn.microsoft.com/en-us/dotnet/api/system.runtime.... [1] https://learn.microsoft.com/en-us/windows/win32/wic/native-w... [2] https://learn.microsoft.com/en-us/lifecycle/products/microso...

Author of the post here,

We wanted the option for distro maintainers to include .NET in the native distro package feeds. This means that distro maintainers have to build the product, not us, and that means creating a build system that meets their requirements. So you either end up with two build systems, or you try and unify. The only direction that it's feasible to go is towards the Linux distro model. It's the most restrictive.

The good news is that the distro model is SIMPLER. It may not be the most performant. A really good distributed system with caching would be far faster. But that's not a solution that's easy to implement or compatible with distro maintainer workflows. Optimizing for simpler in this case is better though. We want the community to be able to participate in a meaningful way. Build for BSD, build for S390x, build and include in distro feeds, etc. We can't feasibly support every platform and scenario that the community wants.

Why is Microsoft's developer division among the best in the industry while the rest of the company (except enterprise sales) is the literal embodiment of incompetence and enshittification? How have they prevented the pervasive cultural rot from affecting them?

On images... I think it might be best to handle a lot of it outside the core... possibly a nuget package that embeds ImageMagick, OptiPng and some other utilities for the purpose of image manipulation in general. The .Net experience itself has always been somewhat poor here.

As to the breaking changes... .Net Core 1.0 was nearly a decade ago... I understand that some people may want to continue running Windows 7 too, but eventually the world moves on and you either update or use a stale version.

The shift to Core and the breakup of a lot of bits comes down to the need to better support running on platforms outside windows... or, .Net itself would have likely died off completely. Most of the .Net projects I've worked on for close to a decade now have been deploying to Linux/Docker... If it weren't for Core/5+ as a shift, it would have been under another language/toolkit entirely.

Since .Net Core 3, I haven't really experienced too many breaking issues that directly affected me... mostly been relatively easy to update my target framework and dependencies. I mean, it's slightly time consuming, but nothing like updating say a React project that's been sitting for even a couple years.

I know their release/LTS cycles are now much shorter than the 20+ years that some framework versions have seen, but keeping things "current" hasn't been that hard. IMO, it's just part of maintenance for "rapid" software development. Companies want software in weeks instead of many years of planning, that means ongoing maintenance work.