FYI: Support ends for older Visual Studio versions in April Microsoft has dropped a gentle reminder that the clock is ticking for older versions of Visual Studio. April is set to be a busy month for VS admins. Mainstream support for Visual Studio 2017 ends on 12 April (although there will be another five years of security fixes for v15.9). Support for Visual Studio 2019 v16.7 ends on …
Depending on the age of your code and the version of VS you've been using, you may find that the result of an update is simply that VS no longer recognises the format of your elderly project files. I seem to recall that there was exactly one version of VS that was capable of converting between the original .Net Core project format and the subsequent one: the capability was dropped from future versions.
In my experience you have two options: either you update VS on a regular basis - which will normally ensure any format conversions will work, at the expense of potentially having to fix things in the code which have become deprecated - or stick with the version you used to create the project in the first place, accepting the support limitations.
"you may find that the result of an update is simply that VS no longer recognises the format of your elderly project files"
Visual Studio forward / backwards compatibility of project files is... barable.
But that is why CMake is so popular. You chuck away the old files and generate fresh ones based on a definition file. As a bonus it also gets you away from lockin to a single toolchain / OS.
Before CMake was really around, this was always one benefit of simply using nmake Makefiles instead. Though these always confused the hell out of our more junior developers who had never encountered them during their education.
>Though these always confused the hell out of our more junior developers who had never encountered them during their education.
nmake is like other Microsoft tools -- it works just like the regular make but its annoyingly non-standard. Like other Microsoft clone tools you can trace its provenance back to the DOS days where it was a cut down copy of the original.
The problem I've found with updating toolsets is that maintenance requires us to keep old toolsets for bug fixes -- a compilation with a brand new toolchain version is effectively a new product and needs new testing and potentially certification, This might not be an issue with applications, code that's being updated every few months, but for embedded products this is really important.
A couple of weeks ago I found myself writing a utility in Visual Basic 4... Not a very sophisticated utility admittedly, with one line of working code : End.
Due to my objections to discarding perfectly good hardware my scanner runs on Windows XP in a virtual machine - no later drivers. The equally antiquated scanner software insists on loading an app against the image after scanning. It had never crossed the 'so annoying have to do something about it until I had about 50 80 year old documents to scan and didn't want to mess about. Hence the app that starts and immediately stops. So I wanted a compiler that would run on XP and the VB4 CD was the first one out of the dusty drawer. You see dear, there is a reason for keeping all this old junk. Never know when it might come in useful.
And what are you supposed to do when you are writing a multi year project (> 3 years) ????
Having to upgrade continuously to new versions of visual studio plus also other tools it soon becomes a real pain to co-ordinate and keep up to date.
Expecially when you are developing for an external customer (s)
I released the first version of my XML merge tool over 11 years ago. It's survived numerous updates to Visual Studio and will survive many more (I plan on upgrading to VS2022 soon).
Upgrading to a new version takes maybe a few hours - a day tops if you have to fix code to keep up with language changes. That's one day every couple of years. If you can't handle that, maybe software development isn't for you. Obviously there are certain things you don't ever want to do - like upgrading within six months of a launch date, for example. But generally speaking, you don't gain anything by sticking to old versions. The more you do, the harder it's going to hurt in the future.
Maintaining backwards compatibility for paying customers can be a little harder, but if it's costing you that much, maybe you need to take a closer look at your development processes.
I very recently setup a workstation for driver building, used 2022, and found when it was time to build, that the rest of the Microsoft battleship hadn't followed and had to tear it all back down and install 2019. Does anyone know if the toolkits have been updated? I see the WDK website claims it is so, but I'd really rather not go for another tour of their carnival of souls if I can avoid it.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
