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.
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.
> 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!)
For writing excel formulas, while I think you can use VSTO/COM, you will get a poor performance if you do. The "right" way to do it is with ExcelDNA/ManagedXLL. But the excel calculation engine was never designed to support async/await, and your calculations operate within a UI thread. So if you need to make a network call in one of your excel functions, you quickly run out of options.
RTD functions are a different thing. It may be useful for certain cases but in my usage would break the calculation model, as the calls must be made in a given order, and must be refreshed by the user deterministically. I can also build some more complex workaround, like calling a different process, though the antivirus in the corporate environment I work in is unlikely to like that.
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.