I think that the problem is that MS is killing a lot of indepent languages. VB6 depends just from 1 dll ( MSVBM60 ), but VB.NET and above need .NET Framework installed. The same is happening with C++. Our luck is that we still can program stand alones programs ( that don't depend of external DLL ) in MSVS.
Sorry, but I think the problem is that you are not aware of why VB was killed. If you know programming well (on the level where you would say "oh no, not again" instead of "I don't know how to do that" if someone ask you to write a compiler) you have no problem understanding what is happening. While some people where regretten the death of VB, professionel programmers around the world where popping the champagne bottles.
VB was killed because it was a horrible language. Not just a bad language, no horrible. The syntax itself is goofy, but that is not really the problem. The problem is a lack of completely fundamental requirements in a modern environment - requirements like using garbage collection instead of reference counting, full exception support, and full support for object oriented programs (not an addon like VB has). VB had developed to a hack over the years (with it's pseudo object orientation etc) and the end of the line had been met - it was not possible to add the requirements of a modern environment anymore. And without it, there where two choices. Either MS should not implement modern libraries in the OS (so no WPF, WCF, or WF), or they should drop VB. As the world has to move on they did the obvious - dropped an old language that was too old to be fixed. How could that possible be the wrong choice?
And now we are at it, the only environment that actually supports simple deployment is .NET. It has a single runtime setup that is distributed as part of Windows Updates - and it will obviously be included in the OS going forward. VB programs ends up requiering one or another COM component (and now we are at it, COM is another outdated monster that needs to be killed so we can move on to better things) as soon as it leaves the "Hallo World" level. C++ does not support side-by-side install of DLLs so it's just DLL hell waiting to happen.
Its very miserable programming a GUI app in C++ without .NET, but at the end you get an independent executable and a very, very faster app than if you had used Framework ( because it really kills the startup performance of applications ).
Yes, it kills performance loading all the systems ensuring your program runs correctly - protected from your bugs, or your attemts to attack my computer (you as in "the programmer", not you personally). Let me see - wait an extra second to load, or run an insecure program - hard call? NOT. I am not the only one who is now ALWAYS choosing a .NET program over a C++/VB program if the choice is available. If it is not available I would require a lot more confidence in the programmer and expectations the program will be really beneficial before I try something as stupid as running C++/VB programs. And we are getting more and more thinking like this - as people become more aware of what .NET is and why it is insane to allow anything unmanaged to execute on your system.
I don't know what to do. I continue to program in VB6 because the IDE opens very fast and when I run my app, it opens instantly, different from VB2005 or any other tool using Framework.
I don't really know what to say.... the time you get back from using a modern programming environment over something as old as VB comes back to you so many times more than the time you loose waiting for your IDE to open. It just makes no sense.
So I don't know what is worthy: use a 9 year old IDE, migrating to VB2005/C++ with the framework or studing a lot of C++ to create a GUI application independent from all those dlls and ocx.
Fergo
Neither is worthy - move on.
One way might be to move as much C++ code into library dlls as makes sense - these can be then used with C# without changing the code. It does mean that C# will treat them as unmanaged resources.
