Here are
some comments I found when I googled "visual basic 6" under "news":
While VB6 was _released_ in 1998, the long haul to .NET meant that it was only replaced at all less than four years ago, and only replaced by a practical replacement (I tend to ignore VB.NET 2002/.NET Framework 1.0) under two years ago. That isn't long enough to migrate.
However, the petition calls for something impractical - integration into the current Visual Studio IDE. 'Classic' VB is just way too different. The designers aren't going to work in the new environment. The debugger is based on an out-of-process model, unlike VB6's in-process host (where your code ran inside the VB6.exe process, and could crash the IDE). Debugging is one area of many where VB.NET is simply massively superior to its predecessor.
Businesses do have quite large numbers of legacy VB6-based line-of-business applications. As a bespoke solution provider, we've written a number of them - we now do new work in C# or VB.NET but maintenance and extensions to older projects are much cheaper without translation, which would take longer and hence incur extra costs.
===========
I work for a large global corporation that employs close to 50,000 people. We have quite a few applications written in house in VB6. These aren't toy apps, these apps are used as front ends to systems that process tens to hundreds of millions of dollars. .net isn't an enhancement to VB, it's a replacement language. Dill weeds like yourself that state 'spare us the complaints' and 'it's time for an intervention' clearly have absolutely no idea what life in the real world is like. It seriously *******me off when people make such stupid blanket statements. It only serves to prove your absolute ignorance.
===========
Try to see this from a corporate programmer's point of view. Microsoft so drastically changed the grammar and rules of this new language, it made porting many of the existing VB6 apps near impossible. And with corporate budgets as tight as they are, people are stuck using VB6 even today.
What M$ should have done is made the first update after VB6 more of an incremental upgrade - changing some things for the better, but leaving others alone; ease the burden of porting our corporate RAD applications. Then, the next version could enhance that even further. SPaced properly apart, these "baby steps" would have helped developers migrate. Instead, M$ chose to jump five steps forward, leaving developers to either buck up the large amounts of cash to perform these insanse ports to the new platform, or wither and die with their now legacy apps.
===========
Hey Dill Weed who works for the little 50,000 user company; I am the assistant to the CIO for our company that employees over 79,000 world-wide. We too have quite a few VB6 apps litering our operations and a few of them contribute to the multibillion dollar operations we run. My reaction to the end of VB6 support is: So what? It's not like VB6 will stop working or will any of the apps written in it. Not that we'll have any shortage of VB6 era programmers (unfortunatly) and there are mor than a ton of 3rd party add-ons that still work just fine with VB6. You act as if a switch was to be thrown that would turn all these apps off.
AND, Paul is right - time for an intervention. Start now using .net, slowly move to the current generation of tools/code. Just because you work for such a large company it's obvious that you are not in charge there because your shortsighted knee-jerk reaction sounds like that of a VB6 programmer who has no .NET skillz and is therefore worried about losing his job to someone who does.
===========
Another aspect to the still prominent use of VB6 is it's compatability with VBA code inside office apps such as Excel and Word and Access. As an Architect, I have developed many apps in VB6 that integrate to VBA seamlessly. I can write an app using a combo of VB and VBA without any problems using COM interfaces. At this point, VB.net addins loaded into Autocad cannot be unloaded from AutoCAD without a restart; not a very viable development model. Until the .net platform is as ubiquitous and well integrated as VB6 into the wide range of business applciations, the older version will still be in high use.
If Microsoft ( and other companies integrating their technologies ) would give me a good enough excuse to switch, I would...
"If Microsoft ( and other companies integrating their technologies ) would give me a good enough excuse to switch, I would..."
Bad idea. Even if MicroSoft came up with a viable *business* case to switch from VB6 to VB.Net, on a corporate level you are setting yourself up for failure when MicroSoft's *next* release of VB.Net does to the VB.net what VB.Net did to VB6 (i.e. fail to implement backwards compatibility).
To go to VB.Net from the corporate perspective (a very different bean-counting viewpoint from that of a single independent programmer), your teams have to learn an entirely new development environment, a new programming language, a new architectural paradigm, as well as give up the superior VB 6 integration with VBA office apps such as Autocad, MS Excel, MS Word, MS Access, etc. Oh, and you also lose VB 6's superior error detection and correction capabilities.
And once you get your team through all of those hurdles, your corporation has to antitcipate that MicroSoft is once again going to screw you by killing backwards compatibility again when they come out with the next release of VB.Net or its successor ("Wired.net" anyone?!). I mean, if MS killed backwards compatibility going from VB 6 to VB 7 (ooops, VB.Net), then why wouldn't they kill it again going from VB.Net to VB 8?
Essentially, MicroSoft is saying that VB should not be used by corporations, only by independent programmers who don't have much at stake (e.g. having to rewrite large amounts of legacy apps). After all, re-work for the sake of rework is hardly what project managers want to present to their corporate CIO's.
Technically, VB.Net is inferior in multiple areas (e.g. no backwards compatibility, VBA support/integration, error detection and correction) to the older VB 6, anyway. Worse, if you make the jump to VB.Net, at any moment MicroSoft is liable to screw you by coming out with a new version of VB that once again isn't backwards compatible.
Can you imagine the howls from the C++ crowd if some new version of C++ didn't support older C++ code?!
It's utter madness, yet that's precisely what MicroSoft did with Visual Basic. At a corporate level, everyone besides MicroSoft has got to get away from VB; you simply can't justify going forward with release plans that may or may not be backwards compatible in the future, much less be technically inferior to the older releases in the first place.