VB runtimes gave the whole framework thing a bad taste, MFC didn't really help either (and .NET ... still fits the same bill).
Here's the thing, One .NET app is not a big deal, and two usually isn't either. But... When you start getting 4, 5, 6+ especially when different service pack levels are required ... Things tend to mire quickly.
easily 90% of .NET app come with some type of installer. (and...) Not all installers are intelligent enough to stop and make sure the runtime package they're holding is necessary. So you install app A and app B explodes (I see this a lot). ...Becaused something got moved/changed/updated/tinkered with (what shouldn't). Now if app A just so happens to be a mission critical vertical market management application (and it usually is...) You-Are-Screwed.
I'm usually looking for apps that are small, portable, and have as close to a zero presence foot print as possible. If I have to install framework anything to run an app, then I'm no longer troubleshooting (Just) the problems that existed before I got there - As I now have to deal with the very real possibility that there is now a new problem that I just created by installing X which is (conflicting with Y) now compounding the issue that got me called to the site in the first place.
Stoic Joker you are 110% right!
Sadly enough .NET runtime has replaced non-.NET runtime before .NET technology got stabilized.
There is an interesting conjecture & solution I'd like to suggest. I can't say for sure but I think Java does it. *I think Java allows you to run more than one runtime build at a time!* Go to www.java.com
& you will find that they never give you a plainspeak answer to the question - Does one need to uninstall the previous build of runtime before installing the latest runtime or can both co-exist.
It would be nice if Windows works out a similar interim solution. Oh I am not referring to compatibility mode.
Till such time .NET technology stabilizes Windows OS should allow both .NET & non-.NET runtimes to run concurrently during a computing session with the proviso that the non-.NET runtime has the upper hand in deciding how computer resources would get allocated in case of a conflict. That's because presently non-.NET technology has stabilized more as compared to .NET technology!
After .NET technology stabilizes worldwide subsequent OS's could shift to .NET.......but not before then. This approach looks practical to me. I know in the interim third party developers would face the added challenge of developing apps which get along with both runtimes.