Microsoft emits long-term support .NET Core 3.1, Visual Studio 16.4 Microsoft has released .NET Core 3.1 – a significant milestone as, unlike version 3.0, it is a long-term support (LTS) release, suggesting that the company believes it's fit for extended use. It is accompanied by Visual Studio 16.4, also an LTS release. Microsoft dropped the veil on .NET Core 3.0 a couple of months ago, a …
Ahh, once again my thoughts that .NET is not a stable choice for applications with long lifecycles are demonstrated. It amazes me how many developers yell fa-la-la and carry on - probably the difference between contract and permanent mentality.
For throwaway, rapidly developed applications it's fine. For things that serve for more than about 5 years; plan on periodic refactoring or hosting on obsolescent platforms with attendant risks.
You took the words out of my mouth. Have an up-vote.
I was left thinking that, for all it's issues, Java is still a good bet if you're looking for longevity. I have a ten year old Java application (nothing fancy, a CPU emulator for an old CPU that we had to get to grips with) that runs with a Swing GUI that still works perfectly on any platform. Windows, Linux, Mac. It just works. I can't remember any issues with it. I ran it recently (just to see if it still works) on a Linux Mint build and it was perfect. The binary is a little more than 10 years old.
I have FORTRAN IV code written originally for an S/360 mainframe in 1977 still in production. No problems whatsoever. Move that code to .net and I'll spend longer handholding it through UI changes and dependency hell than I will on getting on doing my job.
Java had my attention briefly; but Python is winning me over for anything new. And if I need serious performance there's not really any substitute for C or C++.
X years of support just means Microsoft will issue fixes and diagnose bugs for that period of time. If your application runs fine when you build it and you deploy it and you don't mess with it it'll continue to run fine. It's no different from OS support, even Linux distros have EoLs. Minor tweaks every three years if you want to upgrade to use the newer features in the next version or you want to receive potential security upgrades is hardly a big ask.
As for Java, that gets security updates all the time. If you just left it alone on a server and never touched it after release you'd likely be running on an insecure platform.
The controls in question were deprecated 14 years ago. They haven't been available in the toolbox for nearly that long. Furthermore, a new version of .NET Core isn't going to mean you have to refactor your 13 year old software, it will carry on working as it did before.
From the linked blog post:
These controls were replaced with more powerful controls in .NET Framework 2.0, back in 2005. They have not been available by default in the Visual Studio Designer Toolbox for many years. As a result, we decided to remove these controls and focus only on the new ones.
Except if its an internet available application and a security bug in .net framework appears that allows bypassing of security features use in said application, then the framework needs updating to fix it, but as its only supported for 3 months after then previous release (current) or 3 years (LTS), then you will need to update and possibly refactor. Or if you are in an environment that requires security audits, then support is required, and well you should be using only supported frameworks anyway for security reasons.
.NET (classic) for example 3.5 support ends in 2028 (extended support), 20 years of support.
But Microsoft is now 'modern', with 'modern' support life cycles, which means very little support and if it becomes boring will just dump it.
True, true but you could also argue that many institutions such as Banks etc. hold on to their platforms for far too long and despite having the biggest pockets continue to invest in outdated technologies.
I find the rate at which platforms appear and disappear most alarming but at the same time I see it as the way things are.
You could argue that the game of football is not what it was and its not how you like to play the game. However if you want to work in the premier league you need to start playing the game the way it's being played even if it doesn't last for long.
Applications that are wonderfully complete, work 100% and never need updating or upgrading don't make any money and don't need any programmers to maintain them.
once again my thoughts that .NET is not a stable choice for applications with long lifecycles
And once again you'd be wrong.
.NET is one of the premier language frameworks on the market - if you're not using it as a default these days then you're probably doing Python or C++. The frameworks all have extended lifecycles, and there's no reason you have to move from .NET to .NET Core unless you want to (there's advantages in why you might and reasons why you might not).
probably the difference between contract and permanent mentality
Were such a thing to exist, this would not be it.
If you're not using .NET Core as your default language choice you're stealing from your employer. Yes, there's a plethora of situations where you wouldn't use it, such as where you have to be very close to the metal, but Java is basically dead - there's no future in it now.
For things that serve for more than about 5 years; plan on periodic refactoring or hosting on obsolescent platforms with attendant risks.
Micro Focus Enterprise Server for .NET began development nearly 12 years ago, with an initial release around a year after that. It's a major .NET application - a distributed application server that emulates mainframe CICS and JES. Around 5500 source code files, in hundreds of projects. I won't bother counting SLOC.
We've never been forced to refactor due to .NET Framework changes, or to "host on obsolescent platforms". The .NET Framework is still supported and still receiving updates. ES for .NET runs on all supported Windows versions. (And under Azure too, as a set of worker roles. Or, of course, in VMs.)
You may not like .NET. That's fine. And Microsoft have certainly abandoned some .NET technologies, such as Silverlight, while letting others such as WCF languish after they reached a certain point. It's also true that Microsoft would prefer applications move to .NET Core, and let them abandon features of Framework they're not planning to port to Core.
But it's simply not true that all non-trivial, long-lived .NET applications have been forced to change.
Umm, no. I have a .NET 2.0 application from 2004 that's still in use, will happily run on any Windows box from XP to 10, and I have no reason to believe that it's going to stop working any time soon.
Sure, if I wanted it to run on Linux or Android or whatever, I'd have to do some work on it, but that would hold true for any application that was not originally designed to be multi-platform.
If that application of yours does any engineering critical maths you may want to review it. In the shunt from XP to Win7 one of our older .net apps returns different answers to the same questions - later narrowed down to behavioural changes in specific patches of the framework. Binned it entirely here because bloated binary blob leads to untraceable errors. Not good enough when lives depend on the results.
So again, for throwaway apps, go right ahead.
No, lives do not depend on that program, and no, that does not make it a throwaway app, and also, no, it does not hit any framework bugs, or it would have been found by now. By that line of reasoning, you shouldn't run anything critical on an Intel CPU, because of that floating point thing a while ago. The tools you use can be buggy, you still do the work.
"I'm pretty sure Windows Forms is still Windows only it just runs on the .NET core framework now."
Not sure about on .NET core but Mono provides an implementation of WinForms that is fairly good if you stick to pure .NET bytecode.
The problem is that loads of the gimmicky third party stuff that everyone uses pinvokes loads of native WinAPI stuff which cannot work on non Windows platforms (or even locked down Microsoft crapware like Windows RT)
So again, even if .NET core did provide winforms, it is still not fantastically portable until people start using it in a portable way.
While I'm not a Windows app developer (I am a web developer though) I struggle to make sense of the options available. It seems there's three different ways to build GUI apps for Windows, but none of them is quite the best, they have different strengths. There's one that's dated with broad adoption, and another that's modern but feature-incomplete and won't run on Windows 7 or older.
Is it any wonder the Microsoft Store is missing a number of key apps, some devs must looking at this and deciding it's not worth the hassle. The reason Windows took over the world in the first place was software support and MS are in danger of throwing that away if this doesn't come together soon.
I am pissed that they didn't move Web Forms forward. Yes, it is old, but, it still works great. I have been using Telerik's UI controls and it has been a highly productive environment. The UI controls are very robust and AJAX enabled. I almost never have to even write a line of JavaScript. IMHO, Microsoft had the design right to begin with. Yes, the pages are big with VIEWSTATE, but, for intranet applications, it's not really an issue. And IMHO that is something they could have fixed. However, the took Web Forms and threw it out and replaced it with a less functional MVC based framework which or all practical purposes was just a rip off Ruby On Rails. Also, I am not sold on client-side applications. For the database driven applications I'm working on, there is no need for it. Server-side with AJAX enabled controls works just fine. I am not happy at all with Microsoft not moving it forward. Luckily, they made it so that EF Core 3.1 can run on .NET Framework. On 3.0, it only worked on Core. At least they fixed that.
Presumably you want your Active X back as well?
Good1 news! ActiveX is back. It's supported by Edgium in IE Mode. (IE Mode is really just IE 11 running in an Edgium tab, so you get the best2 of both worlds.)
1For sufficiently small values of "good".
2For sufficiently small values of "best".
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
