Im planning to upgrade a large vb6 application to .net. The project uses many third party components eg VSFlexGrid as well as crystal reports. It also uses old VB6 dlls whose source code is unavailable. My questions are
I would welcome any useful input from anybody who has done this before.
Here is an adaptation of a couple of my answers to similar questions.
Converting automatically is a better choice than rewriting. It's a common pitfall to start out optimistically rewriting a large piece software, make good early progress fixing some of the well-known flaws in the old architecture, and then get bogged down in the functionality that you've just been taking for granted for years. At this point your management begin to get twitchy and everything can get very uncomfortable.
...and here's a blog post by a Microsofty that agrees with me:
Many companies I worked with in the early days of .NET looked first at rewriting driven in part by a strong desire to improve the underlying architecture and code structures at the same time as they moved to .NET. Unfortunately many of those projects ran into difficulty and several were never completed. The problem they were trying to solve was too large
This excellent Microsoft page recommends two third party migration tools as better than the (no longer available) built-in VB.NET upgrade wizard - Artinsoft and CodeArchitects VBMigration. I believe they have some support for common third-party controls and DLLs - Artinsoft suport these. It would be worth contacting them with a list of your dependencies. VBMigration has a free tool that will list the dependencies for just this reason. Also worth contacting the original vendors in the hope of a .NET equivalent.
The Microsoft page also says:
Performing a complete rewrite to .NET is far more costly and difficult to do well [than converting] ... we would only recommend this approach for a small number of situations.
There are many more C# developers than VB.NET developers on Stack Overflow, so you will probably get several answers recommending C#. Also historically Microsoft has tended to support C# more enthusiastically in terms of code examples for new parts of .NET and so on. But Microsoft does now assure us that:
Both [C# and VB.NET] are first-class programming languages that are based on the Microsoft .NET Framework, and they are equally powerful.
So it's a personal decision whether you want to choose C# or VB.NET. The Artinsoft tool claims it can convert VB6 to C#.
EDIT: I just found another offering - NewCode - through an ad on a programming website!
My snap judgement is that the website isn't as detailed as the two competitors I've written about above. That may be unfair. Some guy at Microsoft Ireland blogged about them - I think they are based in Ireland. Apparently the tool converts your VB6 to a DSL and then to VB.NET Winforms, C#, WPF, Java...
Upgrading; even if mechanical tools exist, this will not really do much for you. It won't make it magically well-suited to .NET, or make much decent use of the framework. I'd always prefer a re-write in this scenario, but that does have associated risks / costs. For example, some colleagues of mine are currently re-writing some VB6/ASP/COM+/xslt code to use ASP.NET MVC - most of the "interesting" code is actually business logic, which isn't massively hard to port (the trick is testing it ;-p). It helps that the layout of our VB6 code is granular, allowing us to migrate individual slices, without having to push the whole lot at once.
The 3rd party controls will be a nuisance, and it sounds like the other dlls might have to be reverse engineered. Not trivial.
The choice between C# and VB.NET is largely secondary. Both have some minor advantages, but overall you can do most things with either. If you need COM interop, then VB.NET might be useful (either for everything, or for just a specific assembly) - but C# 4.0 (in VS2010) will plug this gap via the new dynamic
typing and the no-PIA changes. Overall, I vastly prefer C#, but that has to be a local decision.
I talk about this issue here
The first and most important step is make your existing application as .NET like you can. Anything VB6 specific or relies on a 3rd party control get as much of it behind interfaces as you can. The interface will show exactly what you are using the 3rd party stuff for and what behaviors first. By doing this in VB6 first you can run unit and integration tests make sure that behavior is PRESERVED. That the key element that the behavior of your application is preserved.
As for the issue between C# and VB.NET. There is functionally little difference between the two languages. One of my conversion project back in the 90s was taking my Company's CAD/CAM application from a BASIC dialect known as Rocky Mountain BASIC into Visual Basic 3. We had a few false start before that and it was felt and later proven to us that it is far easier to preserve behavior by switching to another BASIC family langauge than to convert over a completely different language family like C.
Understand in our circumstance we have a lot of math heavy subroutines and math is one of the few areas that remains relativity consistent over the BASIC family of languages. So my experience my not be a 100% applicable to your case.
It is my opinion that the terseness of C style languages is a detriment to long term maintainability (decades). However to be fair it is a minor point at best. I have extensive experience in both languages as I write and maintain a simulation of Mercury and Gemini Space Capsule written in C++ with some utilities written in C# in addition to the CAD/CAM program in VB6/VB.NET for my company.
Right now our .NET conversion is focused on VB.NET. I found automated tools near useless as we are a heavy graphics oriented program. Luckily we don't use the VB Graphics calls directly but put everything behind a canvas interface. For printing compatibility we use the Printer Compatibility Library from the VB Power Pack as a starting point.
We have a tool that we run our code through that converts all integers to type Int16 and all longs to type Int32 plus a few other commonly done conversion. Then we place the converted class or routine into our .NET library and run unit tests. The results are compared to the same tests ran on the original VB6 code.
The biggest pain in the butt has been the forms. Simple dialog are OK but for the more complex forms we just have to reimplement. Again our forms lies behind interfaces in our original code so while it is work it is straightforward for us to see what to do.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With