Hi, I was wondering if there is any possibility that MSFT could make the VB6 Conversion / Upgrade wizard open source. I think it could really help those of us whom have a lot of VB6 code that we'd like to migrate to .NET speed up the process.
I am the head programmer of Plasma Automation and we make a CAD/CAM application using VB6. (http://www.plasma-automation.com). Just as important I ported this product from its HP's Rocky Mountain Basic to Visual Basic 3 then later did a port to Visual Basic 6 and did a rewrite to take advantage of the new object oriented feature to escape memory limitation and enhance our ability to add new features.
When we choose Visual Basic 3 from Rocky Mountain Basic it was because of Microsoft supporting estentially the same syntax for over a decade of previous basics. About the only construct that didn't make it through to VB3 from QuickBasic was Read...Data. The remaining print, file, and graphics commands could be replaced on a one for one basis with their vb equivalent.
When I went to an object oriented approach in VB6 the fundemental routines often remain exactly the same with the same behavior. Because VB6 supported the same syntax as VB3 I was able to upgrade piecemeal testing the new code alongside with the remainder of the application that was using the original VB3 code.
With VB.NET Microsoft has junked that. The choices made the upgrade process as difficult as the orginal Rocky Mountain conversion instead of making as easy as the move from VB3 to VB6. At first myself and lot of my fellow VB6 programmer nodded our head and because the changes were REQUIRED by the use of the .NET framework.
Then came F# by Microsoft Research Then came Mono which make the whole internal framework clear Then came Ruby.NET, and a myriad other langauges that you could copy and paste from their non .NET version Then twin kickers that really ticked me off is C++.NET 2.0 and the beta LINQ addition.
The last two demonstrated to everyone that it doesn't matter what the syntax is as long as the IL works you can write a compiliers.
So there was no reason for Integer to produce a Int32 instead of a Int16 (the same for long) There is no reason not to have arrays that can have arbitary lower bounds (just produce IL that offsets the index by the lower bound) No reason not to have Gosub and Return
What is unfathomable to me is that Microsoft produced the single most popular programming langauge on the planet in Visual 1.0 to 6.0 and then killed any reasonable upgrade path. The the only type of application artinsoft and microsoft wizards are good for are database front end using a report engine like crystal report. For everything else it just doesn't work.
Printer command conversion no options Graphics command conversion no options
While it is nice to hear that you are working on the printer graphics compatibility object why this isn't your frist priority.
Understand because of the past popularity of Visual Basic there are millions of lines of code out there that have to maintained and it is 2005 and still no reasonable upgrade path.
And I have to ask why should I do the conversion anyway. Why should I recommend to my company to invest their bread and butter software in a company that already shown that they would just kill a line of software, even though it was the most popular development tool they had. How long Winforms is going to last in the face of Avalon. What happens after Avalon.
Microsoft has always made good stuff. .NET and VB.NET is a good platform. But that is not enough. Show your VB6 developers the same respect and give us the same options as the C++ developers. We have an investment in our old code as valuable and as widespread as them.
The Visual Basic 6 Upgrade Wizard mainly uses the upgrade engine from http://www.artinsoft.com/ to perform the upgrade. For advanced features you can check out ArtinSoft other solutions.
We are aware of Printer and Graphic issues and will try to find a solution in the next version. Thanks very much for your suggestion.
VB6 Upgrade Wizard
MarkCrowley
Abandoning the Fantasy of VB Migration Wizardry
http://www.devx.com/vb/article/16822
I am the head programmer of Plasma Automation and we make a CAD/CAM application using VB6. (http://www.plasma-automation.com). Just as important I ported this product from its HP's Rocky Mountain Basic to Visual Basic 3 then later did a port to Visual Basic 6 and did a rewrite to take advantage of the new object oriented feature to escape memory limitation and enhance our ability to add new features.
When we choose Visual Basic 3 from Rocky Mountain Basic it was because of Microsoft supporting estentially the same syntax for over a decade of previous basics. About the only construct that didn't make it through to VB3 from QuickBasic was Read...Data. The remaining print, file, and graphics commands could be replaced on a one for one basis with their vb equivalent.
When I went to an object oriented approach in VB6 the fundemental routines often remain exactly the same with the same behavior. Because VB6 supported the same syntax as VB3 I was able to upgrade piecemeal testing the new code alongside with the remainder of the application that was using the original VB3 code.
With VB.NET Microsoft has junked that. The choices made the upgrade process as difficult as the orginal Rocky Mountain conversion instead of making as easy as the move from VB3 to VB6. At first myself and lot of my fellow VB6 programmer nodded our head and because the changes were REQUIRED by the use of the .NET framework.
Then came F# by Microsoft Research
Then came Mono which make the whole internal framework clear
Then came Ruby.NET, and a myriad other langauges that you could copy and paste from their non .NET version
Then twin kickers that really ticked me off is C++.NET 2.0 and the beta LINQ addition.
The last two demonstrated to everyone that it doesn't matter what the syntax is as long as the IL works you can write a compiliers.
So there was no reason for Integer to produce a Int32 instead of a Int16 (the same for long)
There is no reason not to have arrays that can have arbitary lower bounds (just produce IL that offsets the index by the lower bound)
No reason not to have Gosub and Return
What is unfathomable to me is that Microsoft produced the single most popular programming langauge on the planet in Visual 1.0 to 6.0 and then killed any reasonable upgrade path. The the only type of application artinsoft and microsoft wizards are good for are database front end using a report engine like crystal report. For everything else it just doesn't work.
Printer command conversion no options
Graphics command conversion no options
While it is nice to hear that you are working on the printer graphics compatibility object why this isn't your frist priority.
Understand because of the past popularity of Visual Basic there are millions of lines of code out there that have to maintained and it is 2005 and still no reasonable upgrade path.
And I have to ask why should I do the conversion anyway. Why should I recommend to my company to invest their bread and butter software in a company that already shown that they would just kill a line of software, even though it was the most popular development tool they had. How long Winforms is going to last in the face of Avalon. What happens after Avalon.
Microsoft has always made good stuff. .NET and VB.NET is a good platform. But that is not enough. Show your VB6 developers the same respect and give us the same options as the C++ developers. We have an investment in our old code as valuable and as widespread as them.
Rob Conley
Head Programmer
Plasma Automation
Smalldust
lost.sync
We are aware of Printer and Graphic issues and will try to find a solution in the next version. Thanks very much for your suggestion.
Best regards,