There is a migration, though slow, from VB6 to ASP.NET C# stuff.
We use VB6 because of the component-like nature of how it can integrate with other parts of a larger application--and it usually doesn't have catastrophic failure (like a segfault) which can be contained. Another aspect of why it is used is because of the low-memory requirements, which by extension means one server can host more application sessions for more users. (It is easier to upgrade one server's software instance than thousands of individual workstations)
Microsoft produced several migration tools from VB6 to VB.NET over the years. An "Upgrade Wizard" to do a first pass conversion. Some integration tools to run VB6 COM components in VB.NET applications and vice versa (VB.NET code as VB6 ActiveX components).
VB.NET was always meant to be the path forward, and VB.NET, at least, is open source now.
The migration tool was next to useless. Even if, after a lot of effort, you migrated your app it would typically run a lot slower than on VB6.
The only practical way to "migrate" was a complete re-write, that way you could have something comparable in performance to the original app.
And that is why there are still so many VB6 applications around today, the cost of migrating (to an app that was no better than the original) was rarely justified.
Now that Microsoft support VB6 until at least 2025 while VB.Net is falling in popularity (only 12% of .Net developers use Vb.Net now) it looks like those staying with VB6 made the right decision.
«Now that Microsoft support VB6 until at least 2025»
Microsoft only supports the VB6 runtime. The VB6 IDE and editing tools are no longer supported. Building new projects or new builds of VB6 applications is dangerous and unsupported.
«VB.Net is falling in popularity (only 12% of .Net developers»
So what? C# and F# are both good languages, and it makes sense if VB.NET is a good stepping stone to one or the other. VB.NET isn't going anywhere, it's also a good language for those that want to use it.
«those staying with VB6 made the right decision»
Hah. I'm not sure I agree with "right" from your analysis. Those who have stuck with VB6 in spite of all that has happened in language design and platform changes since VB6 was discontinued have certainly decided to be their generation's COBOL programmers. Certainly there will be money to be made there in ridiculous contracting fees for companies that don't know any better, and that's a possible definition of "right decision", I suppose.
What are you talking about? In that very comment I just pointed to several ways that Microsoft (not even getting to third party options) tried to give a helping hand to people to migrate existing projects at the time of the VB6 to VB.NET conversion path. Yes, it wasn't an entirely smooth transition, but there was a forward transition path.
The assistance they provided got better as the years went by up to about the time of vb2008. Even then the assistance was such that migration of existing vb6 code was recommended by microsoft as the option of last resort. By the release of vb2010 microsoft appeared to have given up on migration completely and removed the upgrade tool from the product.
Too little too late is probably a fair description of it.
Yes, but "a bumpy road is still a road". Forward does not imply "painless", and Microsoft did try to help, even if it felt like "too little too late". VB.NET was still the forward path from VB, whether developers and companies liked that or not.
I have some sympathy for Microsoft on this. Some of the changes could have been backward compatible (like making "set" optional). But some breaking changes had to be made. Like making all function parameters byval by default. Having everything byref by default in VB6 was just a bad initial design.
Not sure I understand your second example.
The upgrade code to VB7 could just have inserted a ByRef for every parameter lacking both a Byval and a Byref?
