Friday, August 05, 2005
Porting VB6 to VB.NET
Against the advice of our other wise minds, I decided to attempt to port the application from VB6 to VB.NET (Visual Basic .Net) so that I could take advantage of a couple of the updated features. There are a few places where multi threading will be invaluable - currently the application performs some long tasks that make the user wait for it.
The application is far from trivial - the project involves 43 classes, 26 forms and 4 module files that total up about 1100kB. It also takes advantage of some of the companies old VB5 libraries which had been ported from VB4 themselves. The project depended on four of our COM servers and about six Microsoft COM servers.
Oh yes, and I have never coded with .Net before.
Apparently yes, I am crazy :)
Anyway I started the porting using Visual Studio .Net 2003 the start of last week. I would sift through the errors messages after the vb6 import wizard had done its magic and then go back to clean up the VB6 code where appropriate. Unfortunately more than half of the forms simply failed to convert with no clear indication of what was wrong (it did seem to correlate with forms that used comdlg32 or tabctl32, but that may have been a red herring?)
I decided to try the vb6 import wizard in Visual Studio .Net 2005 Beta. Thankfully this appears to be much improved as every file got converted! There was still something like 250 conversion errors and warnings, but this also appeared to be better than VS2003 managed.
In the last week, I have managed to refactor most of the backend classes. I am not sure whether the front end forms is going to be the easier or harder part. I will comment on this in a later post.
Anyway, the take home story is that VS2005 appears to have greatly improved the VB6 import wizard.
The parts that required the most manual effort in porting related to the quite complex tree view that it used (the method for implementing tree views is different) and the old DAO 3.5 code.
Performance was reduced as well - this may have been because the app used DAO 3.5 instead of ADO / ADO.NET etc.
Subscribe to Post Comments [Atom]
Subscribe to Posts [Atom]