Microsoft starts a grand unification attempt with .NET 5 Microsoft has dropped the first preview of its latest attempt to unify its development platform: .NET 5. The emission follows the releases of .NET Core 3.0 and 3.1 at the end of last year, which saw the end of porting of app models from the venerable .NET Framework. The plan for .NET 5 (now stripped of the "Core") is to unify …
Yes. It's true that Microsoft have dropped some of the technologies they pushed on developers, such as Silverlight. And .NET Core lacks some .NET Framework features which are critical for some applications, such as WCF; I expect that will remain true with .NET 5.
However, in the main Microsoft has been pretty good about preserving APIs. Hell, they're still maintaining MFC, which launched in 1992 and just had a maintenance release last July. I'm certainly not a fan of MFC, but if I were maintaining an application that used it, I'd be glad it's still receiving updates.
Applications shouldn't need to install "various .NET versions". For those that only need the features in Core, the latest Core version suffices; for those that need Framework, the latest Framework suffices. Any application which needs an older version is broken. That's not Microsoft's fault.
350MB is not particularly large given the amount of functionality. The AOJ JDK I have installed is 303MB. Even Linux x86-64 glibc is a couple of MB these days. It can be argued that putting all that functionality in a platform runtime is excessive; but history suggests it's better than a bunch of incompetent application developers all trying to reinvent it.
The first computer with a hard disk that I ever used was a Burroughs B21. It came with a hard disk with a capacity magnificent 5MB - it had to hold both the OS (BTOS) and all the source, object files, executables and data for the programs I was writing (in Pascal). Fun days!
There's a link to a B20 series brochure here for the curious: https://en.wikipedia.org/wiki/Burroughs_B20
I had to manage a Burroughs B20 network. Interesting concept, thin clients with a central bunch of CPU stuck together, along with shared disks. Worked fine, until I was away for a week and came back to find that site services needed the desk it was sitting on, so they just bumped it across to another desk!
The connectors held, somehow, but the HDD didn't like being bumped around whilst spinning. :-(
If it continues with the support only lasting 2 - 3 years then it still won't get the backing from enterprises that don't want to do an upgrade treadmill, just because the support is not there. Old school .Net lasts the lifetime of the OS - which means significantly long enough between required upgrading. I know the world likes to imagine that we are constantly updating our software with new releases - but often as not in enterprises we have a mixed bag of apps and services that have lots of releases - and others that happily live on with no change except for tech refreshes to remain in support and those release costs are just a drag on the bottom line.
This is exactly why this is a good thing, forcing enterprises to keep up to date, we are making sure all our devs pay attention to this going forward, rather than getting into ridiculous situations where you have to support .NET 1.1/2.0/3.5 because devs are too lazy to keep their skills up to date...
"rather than getting into ridiculous situations where you have to support .NET 1.1/2.0/3.5 because devs are too lazy to keep their skills up to date"
The problem isn't the Devs so much, more management who doesn't want the devs to touch it because it already works so leave it alone. Then there is the cost side, updating something costs money, managers don't want to spend money until something blows up and bites them on the ass. Reactive not Proactive.
I like the versioning methods where they add new features and replace old methods while leaving the old code still workable but depreciated. You then have atleast a year (prefer 2 to 3 years) to recode what is deprecated before the next major release drops the old deprecated code and starts the cycle again. Removing the old at the same time as adding new features/methods is fraught with danger. Much better having an overlap where code can be run with 2 compilers that can check the output.
This is why I have a hate-hate relationship with browser-makers.
I hate being responsible for an application depending on deprecated functionality (that Chrome will tend to remove almost immediately).
I also hate being bound to an old browser for compatibilty reasons because an internal site was based on a plugin and there's no budget to rewrite functional and useful software for shits and giggles.
The news that Microsoft is not committing to an evolution of the Visual Basic language is, for me, welcome news. Maybe they should stop all this race to "improve" the developer environment in favor of letting us digest, understand and master what is already out there.
When your goal of mastery of the tools you need to do your job seems to be receding in the distance faster than you can approach it, the process of "keeping up to date" becomes more than daunting...it is demoralizing. I can't imagine how a new person who seeks to become a developer makes the decision on what technologies they should (try to) learn, knowing that while they are in the process of that learning the ground beneath them is constantly shifting with changes that have yet to be used widely enough to know if they are even useful.
We need to avoid the developer's worst error...giving people what you THINK they want instead of what they need.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
