Scott Hanselman

Actually I spoke with someone over the weekend who works for a podunk county school district in Kansas and he uses VB.NET. His sister works for Corillian too.

It's ok, Kansans make fun of you tree-hugging luddite hippies in Oregon too. ;)

It is hard for me to speak to how difficult the transition was from VB6 to VB.Net. I started workign with VB.Net when Visual Studio.Net was in the alpha release. While the syntax of VB6 is drastically different from VB.Net, which I imagine could intimidate people who don't feel a need to move onto a new platform, I think that the amount of time I spent learning VB.Net was quickly made up for in increased productivity when buidling ASP.Net pages versus ASP 4.0 (was that the last release before .Net?). I would argue that VB6 had limitations that VB.Net has removed. I do not think that the time spent learning VB.Net is so overwhelming that the change is difficult to justify.

I am a wholehearted convert from VB6 to VB.NET and C#. However, for a lot of people I work with, the jump is just too big.

I think someone (not necessarily Microsoft) should develop a .NET compiler for VB6 code. It should not be so hard, considering the nature of the VB6 runtime. Let people continue to work in the simpler world of VB6 if they want, but move them forward to a managed environment.

I have a special place for VB6 in my heart. I still love the simplicity and straightforwardness of it. I think that for professional programmers, like probably all of us reading this blog, the transition to VB.NET/C# is mandatory. Even if you don't port all your existing and functioning systems to .Net, as a pro you should be in pace with the new platform and possibly building your new systems in .Net.
But a significant part of VB6 developers are not fulltime programmers. You see, this was said over and over by many, VB (COM) made it so easy to put together some code that many people started using it without any ambition of becoming a programmer. This kind of usage is way more complicated now in .Net. I'd not expect to see the guys over at the RH department writing MS-Office macros in VB.NET or internal utilities with C# and SQL Server Express. There's no realistic replacement for VB6 in my humble point of view.

ps: There was actually a SP6 for VS6. It is supposed to be the last one.

By what commercial measure do you tell a client that he has to upgrade a working VB6 application (to which they never see nor need to see source code) to VB.NET?

The bottom line problem Microsoft has to answer is what is the compelling reason for COMPANIES to pay to have production applications re-written in VB.NET. It cannot be solely to remain current with MS development product cycles.

That is why we are still talking about developers balking at moving to the new platform three or four years after the introduction of the CLR and managed development - there is little in the way of objective, monetized proof to say that .NET "improves" working production applications in a way that makes it mandatory to convert working code. Period.

Some professional developers feel that they have to sign on to the latest and greatest development environment for their own personal earning potential. That's cool and good for the individual developer.

It may not be the best business practice, however, for a company to sign up for the flavor of the month and base your business stategy for the next few years on a platform that has *** still *** not convinced its core developer base to move forward. That is a problem.

Many companies take a long view on their development efforts, realize that there is significant capital investment in their internal software properties, and carefully gauge benefit.

I am by no means a luddite. My customer projects span 20 years. We still have C language applications in production some 14 years after writing them. We have VB6 applications that are 8 years old and still doing what they are designed. Hell - we even still use DDE in some of our manufacturing applications to talk to Allen-Bradley software.

The fact of the matter is that Microsoft HAS to recognize that all legacy software will not move forward if there is no legitimate business (our business, not MS's) to do so. And THAT is the rub.

Maybe it has something to do with the original intent of VB. Traditionally VB has been a language that is geared towards building forms quickly and providing convenient access to data. VB.Net and all other previous VB languages are completely different... so much so, that I do not consider them the same language. IMHO the only reason VB.Net exists is so that Microsoft could target and market all the VB developers out there, and encourage them to make the leap to the .Net platform.

Scott:

You left the one fundamental reason out, which is:

- the fear of object-oriented programming

Most VB6 programmers are less formally trained than, say ones who program in C++ or Java and it is the confusion of breaking their current system into objects and not knowing where to start is, IMHO, the biggest barrier.

- Adwait

Fear are not wanting to learn something new has nothing to do with it.

So what application has Microsoft written totally in .NET that is worth a shit?
Visual Studio - NO, Office - NO, Notepad - NO, Calc - NO.
Why haven't they?

As a developer I love .NET. As a consumer my opinion is much different.
In my humble opinion .Net apps are still not ready for Prime Time. Give me a C++ app or vb6 app over a winforms vb.net app any day. Any one who can't see a huge speed difference is probably on a 4GHZ PC with loads of RAM. Real users in the Fortune 500 companies I service are still on Windows NT and Many on Windows 95. I've run demos of apps in the new whidbey environment where the apps are much snappier on my developer box but degrade quickly when I run them on a machine that is below 1GHZ.

The day Microsoft is writing Office, Media Player, Visual Studion totally in .NET is the day I would expect that Windows Forms are finally ready.

Great conversation. More thoughts here: http://ea.3leaf.com/2004/10/why_dont_develo.html

you've not read this?

http://www.joelonsoftware.com/articles/APIWar.html
How Microsoft Lost the API War

says it all really...

Worst than not moving to VB.NET (and yes that is the reality for most VB6 devs I know), the ones that do make the jump move to C#. I have summarised my view on "why" here: http://www.zen13120.zen.co.uk/Blog/2004/09/vb6-c.html

There would be somebody out there still using VB6 for entirely different reasons than you have mentioned:

1. Some VB6 apps have few hundereds of forms, too many ActiveX controls, just too much of COM, Win32 API hacks that it isn't easy or economical to convert and test.

2. There are many Win9x out there without .Net Framework. To ensure full compatibility, for example to develop signed ActiveX controls, VB6 is usually the only choice.

3. Lots of "architects" who are basically burned out old-timer developers and have now developed high inertia for absorbing new technologies, would resist a switch.

4. Few things like hierarchical recordset with ADO SHAPE queries are easier to do in VB6.

I still do keep VB6 setup on my dev machines however I hardly get to use since .Net betas were rolled out. Should MS support it? Yes. Even though Vb6 user group would be really small percentage of left over from a million it could still easily count to 100s of thousands.