Microsoft throws lifeline to .NET orphans in the brave new Core world Microsoft has reiterated its position that "if it ain't Core you should code with it no more" by distributing a list of what is in and out of its open-source take on .NET. The company's Build event last month had seen the gang tell eager attendees that once WinForms, WPC and Entity Framework 6 had made their way into .NET Core …
So, now, Microsoft open sources WCF and even WF, but, not Web Forms. The ASP.NET team is absolutely horrible. It has been all down hill ever since they parroted Ruby On Rails and got rid of the UI controls. Now Microsoft wants you to switch to Blazor, an as of yet unreleased experimental framework. I'm sure it will work out great, until they pull the rug out from under it like they did with Silverlight .NET Core in general has been one fiasco after another.
As long as my C and C++ projects do NOT have link up with ".NOT" or CORE or whatever they wanna call it, I'll just not care what new/shiny bandwagon MS excretes now and in the foreseeable future...
I still like the idea of being able to let people download a single EXE file, copy it to 'wherever', and just run the application as-is without installing a boatload of "other stuff" and polluting the registry, etc. and requiring elaborate install and/or uninstall processes.
dynamic linking and shared frameworks are SO highly overrated
You must not have heard that the new way of creating .NET Core apps is to include a full copy of .the .NET Core runtime and DLLs with your application. So, you end up with about a hundred different installs of varying different versions of .NET Core. It's great. Way to go Microsoft!
So, after about 19 years of pissing me off, MS has finally realised that all that pseudo web-ishy (AKA that cludgy overweiight client server mentality) crap (I'm thinking as examples ASP.NET Ajax, silverlight and UI controls) they'd been peddling to keep "legacy" VB developers in the loop (instead of shot) is being chucked in the bin and someone indoors has finally realised that the client side is divorced/different from the server side. If Entity "the next version will be better" Framework can be quietly gassed on a darkened night, my life would be complete.
This....
As someone who's recently moved to C# from the Java world I don't see why you need the .net specific frameworks, don't you just chuck some JSON back to whatever UI javascript framework is in fashion these days? Then your UI is decoupled from your backend, and any web dev who can deal with a JSON response can code your UI, none of this MS or non MS distinction? The Java sites I worked on previously just spat JSON to a React front end, you could easly replace the backend stuff with a C# service that did the same thing.
Don't couple your UI to your backend if you don't need to. (That's the mistake people who saw Oracle forms made in the 90s).
Nothing lasts forever. Microsoft will bin .Net Core one day, you can be sure of that.
Which is a real problem if your business is making reliable use of longstanding applications. For example, I have a service that receives 30M+ requests per day. It's a cranky old SOAP web service (originally hosted on ancient Win 2003 servers), but it has been migrated to a shiny PaaS implementation. I'd like to keep it ticking over with the occasional new features for a good few years without the need to redevelop it for redevelopment's sake.
Microsoft will bin .Net Core one day, you can be sure of that.
This is a vapid observation. As you implied yourself, no product line will last forever. The question for developers is whether .Net Core is likely to last as long as their application. Frankly, that's hard to say for anything with a reasonably lifetime, as Microsoft's abandonment of Silverlight, WCF, etc show. I'm not making any judgement about whether those technologies were worth preserving or indeed using in the first place - just pointing out that Microsoft hasn't shown much commitment to the developers it encouraged to use them.
On the other hand, there were plenty of people who were dubious - with good reason - about Windows NT when it first appeared on the scene, and plenty of vendors who've been able to sell software on that platform for a quarter century.
As in most domains, making predictions in this domain is a fool's game. There's value in assuming that a platform might become obsolescent long before you're done with it, and planning based on that. But there's also value in giving customers what they're asking for, even if it requires using a dubious platform; and there's value in getting to market quickly, and in making use of widely-available labor, and so on.
The posix and sockets APIs I learnt 20 years ago is still relevant today. The only thing I need to keep up with are the 3 yearly increments of the C++ specification and an occasional API for a DB, but thats pretty much it. I genuinely feel sorry for Windows devs constantly having to play catch up just to stay still with MS and its pointless development enviroment changes. Wasn't .NET supposed to make things portable to different versions of Windows without DLL hell? Sounds like they've simply made things even worse.
It also helps keep .Net trainers in business. If you haven't worked in .Net et al for more than a year or two, you need to go back to school, or at least spend about as long as you've been out, re-learning all the crap they've changed.
On a positive not, I did get a very pushy recruiter to leave me alone after I informed them that I was five years out of date on .Net. ("We'll have to get you trained up again then, let me sort out the details..." and never called back. I call that a result!)
Your confusion is clear. Your list of technologies goes far beyond what the .NET framework is about! You've conflated web servers, platform agnostic messaging protocols, UI toolkits, database access patterns, network communication standards with the .NET framework, amongst other things.
Still, you are right, the world of software development is a never ending treadmill of changes :)
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
