Hmmm...So when the automobile came into being and the buggies were no longer compatible, you're saying everyone should still be driving around in horse-drawn buggies? If you write ANSI C++ code, it should still compile. If you didn't, that's hardly ANSI's problem.
As to slamming me and my credentials, I was the founder and CEO of a software company that produced compilers and other programming tools for 17 years and am teaching in the computer technology department of a Big Ten university. Before you run off at the mouth next time, you might want to click on the person's name first to see if they have any depth to them. I did so with yours and have a pretty good idea of how you spend your time...I'll stack my credentials against yours any day of the week.
"Hmmm...So when the automobile came into being and the buggies were no longer compatible, you're saying everyone should still be driving around in horse-drawn buggies? If you write ANSI C++ code, it should still compile."
You've misdiagnosed the situation. Even if you wrote your VB code precisely to MicroSoft standards, then it *still* won't compile in VB.Net.
VB.Net isn't backwards compatible; MicroSoft broke the chain. That's like a new C++ compiler that can't compile C++ code from last year. Code written precisely to standards in *any* earlier version of VB won't work in the new VB.Net.
Can you imagine what Java developers would say if a new Java engine couldn't handle Java code that was written to industry standards last year?! Well, that's what VB developers are saying about VB.Net.
Nor is this like the horse and buggy; this is more like last year model cars versus this year model cars, except the new MicroSoft cars won't run on the highways that you built last year because they aren't backwards compatible. You have to build all new highways to run the new MicroSoft cars.