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.
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.
You are not going to like my answer but here goes.
a) Hire someone with a significant amount of experience in building large .Net applications to come and guide the project and teach you.
b) Extract the business requirements from your current application and freeze them.
c) Celebrate the fact that this should be the easiest greenfield application development project ever because you have someone with experience in the technology to guide you, you have mature tools to build the application with and have a well defined set of requirements, so you know exactly what to build.
P.S. At this point I would not bother with Winforms. I would jump straight to WPF, you'll thank me later.
P.P.S The language really does not matter (C# or VB.Net). The effort will be the same.
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 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...
I would suggest you 'partially rewrite' you application. The fancy name for this approach is strangling (http://martinfowler.com/bliki/StranglerApplication.html).
My guess is that it is a database app. See if you can rewrite some features by directly talking to DB. Don't worry about having users use two app. The old app is bad enough for them to ask for an update.
My other guess is that since it is VB6, it doesn't have very good UI/BusinessLogic separation. That is why auto upgrading will not get you too much.
Maybe I was wrong about your situation. You need to ask you how much you really can get out of the existing code. Buy/Read Michael Feather's Legacy code book too.
VBDepend can help to understand the existing vb6 code before migration, and accelerate the process during migration.