----------
This paided off when we made the transition from VB3 to VB6. Along with the upgrade to 32-bit Windows we took advantage of the object-oriented features turn our application to using Model-View-Presentation to allow more flexiability in adding features for specific customers. Because the core langauge did not change between VB3 and VB6 our testing suite was very easy to implement as a lot of older testing code just transfered right over.
http://martinfowler.com/eaaDev/PassiveScreen.html
http://martinfowler.com/eaaDev/PresentationModel.html
As a result we had a piece of software that was well designed for any future changes in Visual Basic.
However with VB.NET Microsoft made this upgrade more like Rocky Mountain BASIC to VB3 than VB3 to VB6. At first myself and my staff kinda of said "Well if that what it take to get all the new stuff." We schelduled the upgrade for later rather than sooner but planned on doing it.
Then F# came out of Microsoft Research, then RUBY.NET, then we learned more about how .NET really compilied to IL, and how VB.NET and Microsoft.VisualBasic.dll worked together. By the end of two years we decided that Microsoft really blew it and with all the annoucement about changes to the form engine for future versions of .NET (Avalon) we lost confidence that Microsoft will maintain a stable langauge platform. I signed the petition, exchanged emails with Microsoft Managers but they simpily don't get it.
Examples I can give is that Integer compile to Int32 and Longs compile to Int64. While trival on the surface when you have a lot of math and binary routines it is important. Plus the history of BASIC is that Integer and Long definition doesn't change unlike the C/C++ world. You will find this 90% of the BASIC dialect out there even in those BASIC that spanned the old 8-bit/16-bit transition. In 8-bit Microsoft Basic a integer was 16-bit. More serious is the lack of compatibility objects that emulate the graphic and printing commands of VB6. Another is the fact you can't implement a COM interface with properties unless all the parameters of the properties on the COM interface are declared ByVal instead ByRef.
In addition to our main development trunk, I maintain a conversion project that has been worked on sproadically since the first version VB.NET. So my experience with the problems of vb6 to vb.net is not the result of a few days of work. We haven't pushed further because converting tests to pinpoint the difference has been daunting and we are not sure whether problems are because of change in the test or in the code. The real killer is that management realizes that .NET doesn't bring enough to the table to derail our main development in order to get a .net version out.
There is a bunch of other vb6 developer who are similarily fustrated. Anybody who used vb6 for a serious application for anything but a database front end that uses crystal reports has been hammered by this.
I think that vbnc can be used as a basis for a .NET compilier that can create valid assemblies and exes from vb6 code. I am not a compilier whiz or I would plunge in myself. I can learn with some help. I want to let you all know that this problem exist and the MONO vbnc could be the way out of this mess for all vb6 developers. Granted I realize that we can't get the vb6 IDE back with this but if we can just compile our .vbp project files into a valid .NET assembly then we can plan for a rational conversion upgrade.
Rob Conley
Plasma Automation
_______________________________________________ Mono-vb mailing list [email protected] http://lists.ximian.com/mailman/listinfo/mono-vb
