Edit: Uses a shit load less actual energy than full-building a product thousands of times that never gets run.

You only get access to the LTSC channel if you have a license for at least Visual Studio Professional (Community won't do it); so a lot of hobbyist programmers and students are not aware of it.

On the other hand, their existence is in my experience very well-known among people who use Visual Studio for work at some company.

People don't need any UNIX biases to just want multiple versions of MSVS to work the way Microsoft advertises. For example, with every new version of Visual Studio, Microsoft always says you can install it side-by-side with an older version.

But every time, the new version of VS has a bug in the install somewhere that changes something that breaks old projects. It doesn't break for everybody or for all projects but it's always a recurring bug report with new versions. VS2019 broke something in existing VS2017 installs. VS2022 broke something in VS2019. etc.

The "side-by-side-installs-is-supposed-to-work-but-sometimes-doesn't" tradition continues with the latest VS2026 breaking something in VS2022. E.g. https://github.com/dotnet/sdk/issues/51796

I once installed VS2019 side-by-side with VS2017 and when I used VS2017 to re-open a VS2017 WinForms project, it had red squiggly lines in the editor when viewing cs files and the build failed. I now just install different versions of MSVS in totally separate virtual machines to avoid problems.

I predict that a future version VS2030 will have install bugs that breaks VS2026. The underlying issue that causes side-by-side bugs to re-appear is that MSVS installs are integrated very deeply into Windows. Puts files in c:\windows\system32, etc. (And sometimes you also get the random breakage with mismatched MSVCRT???.DLL files) To avoid future bugs, Microsoft would have to re-architect how MSVS works -- or "containerize" it to isolate it more.

In contrast, gcc/clang can have more isolation without each version interfering with each other.

I'm not arguing this thread's msvcup.exe tool is necessary but I understand the motivations to make MSVS less fragile and more predictable.

I got anxiety reading the article, describing exactly why it sucks. It's nice to know from the article and comments here there are ways around it, but the way I have been doing it was the "hope I check the right checkboxes and wait a few hours" plan. There is usually one "super checkbox" that will do the right things.

I have to do this once per OS [re]install generally.

What if it was?

What if it wasn't?

What if you never find out definitely?

Do you wonder that about all content?

If so, doesn't that get exhausting?

I did try using python and js but the variable explorer is garbage due to 'late binding'.

I thought this was just my ignorance, but I've asked experts, AI, and google searched and they unfortunately agree. That said, some people have created their own log/prints so they don't need to deal with it.

As long as you don't give a shit about the fact that your baseline memory consumption is now 500MB instead of 25MB, and that 80% of your CPU time is wasted on running javascript through a JIT and rendering HTML instead of doing logic, no.

If you don't give a shit about your users or their time, there's indeed no longer a need to write native programs.