"First, the degree that VB6 code doesn't compile on VB.NET depends in large measure how you wrote it. A lot of my code ported over with little or no change. The changes that were required were often global search-and-replace edits that were easy to do. True, some things are harder than others, but still not a big job if you designed and wrote clean code in the first place."
Not true.
Any professional VB 6, 5, 4, 3, 2, 1 code written to any published industry standards will include error detection and correction routines that are incompatible, by design, with VB.Net's new architecture.
That's not a global edit/search-and-replace; that's fundamental recoding of your large corporate projects' architectures (meaning, new designs or at the very least new design reviews).
It means that all of your original object, module, application, project, and system testing must be redone, too.
New coding. New architectures. Full system re-testing. All of the above is *mandatory* for all serious "upgrades" of existing VB 6/5/4/3/2/1 applications under VB.Net.
After you complete all of the above, by hand (no automated tool can do the above for you), you are then granted the same functionality as you had in those applications prior to upgrading to VB.Net.
That's an enormous amount of effort for *zero* user-visible enhancements.
Oh, and your VBA integration is also screwed under VB.Net. That impacts your corporate interactions with such daily high-use programs as MS Excel, MS Word, MS Access, and Autocad, among others.
For organizations with large amounts of frontline, daily-use VB code, VB.Net is a counter-productive nightmare.
For individual programmers, especially those who write little tiny test applications that rarely get used by anyone besides the programmer herself, VB.Net's migration from VB 6 code may occasionally appear tame; for everyone else, it's a beast...a cost-adding, time-wasting monster.
VB.Net is a counter-productive nightmare...a beast...a cost-adding, time-wasting monster. As I already said, it depends on what you're using it for. If your building large multi-user enterprise applications, .NET is far superior. If you're building " little tiny test applications that rarely get used by anyone besides the programmer" as you put it, use VB. No one is stopping you, you have the license, and can buy the support. If they eventually kill the support, which being a commercial company they might, if it's no longer profitable, move to something else, or find a 3rd party support vendor. You could also move to a different product, if you want. The sky is definitely not falling.
I didn't say all the code went over without change. However, as far as setting try-catch blocks, how tough is it to look for an on-error goto and change it to a try-catch if you wrote it right to begin with? More importantly, VB6 and VB.NET are different animals. NET is fully OOP-compliant while VB6 isn't, so why would you not expect some editing? I agree, if you don't intend to take advantages of the enhancements to the language, especially the web stuff, just stay where you are.