Friday, August 05, 2005
Porting VB6 to VB.NET
I recently started to breathe life back into some old VB6 (Microsoft Visual Basic 6) code that hasn't been touched for a couple of years. The binaries have been used continous since then, but no-one had touched the code since the original developer left the organisation. Because it is a administration tool that is only used internally we have been putting up with the list of well known annoyances.
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.
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.
Comments:
<< Home
Hi, i'm in the same boat - have an old VB6 app that i need to move to .net. Is there a follow-up to this blog? I.e. how long did it take to correct the classes and what sort of problems did you encounter? Kind regards, Steve.
# posted by 
: 5:30 am
: 5:30 am
Hi Steve, the follow-up was that for this particular application we abandoned the porting effort. I actually got help from someone else on some of the more difficult parts, but the original application was such a tangled web of spaghetti that the porting effort required major refactoring of the code.
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.
Troy
Post a Comment
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.
Troy
Subscribe to Post Comments [Atom]
<< Home
Subscribe to Posts [Atom]