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.
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.
As it's pointed out, you could rewrite your application.
Another solution will be a true VB6 alternative, full compatible. I'm working in a project that want to be a real VB 7: RAD Basic. You could continue working with your VB6 code base in a modern environment.
I have started reworking one of my company's apps written in VB6 to VB.NET. Both C# and VB.NET rely on the .NET framework, and the differences between an app compiled in either one is negligible. Choose the language you and others working on the project feel more comfortable with. One advantage to using VB.NET (though I am hesitant to call it such) is you can use the "Upgrade Visual Basic 6 Code" feature in Visual Studio. There are some things the converter fixes, and a lot it doesn't. If you want to try this, you'll have to clean up your VB6 code:
Even after cleaning up existing code the best you can, the conversion still isn't 100%. You could try this in a separate project just to see what you get to give you ideas on how things need to be reworked. Sometimes forms look ugly after a conversion as well, and for some things you may well end up redoing them from scratch anyway.
A lot of our forms made heavy use of the ItemData property in combo boxes and list boxes which no longer exists in .NET. ListViews also work differently, and none of the drawing functions are the same. Some forms from the app I converted just looked really bad when converted to .NET controls and didn't behave the same way, so I'm just going to end up reworking these from scratch. The advantage is I get to rework processes that were not very efficient to begin with, but of course this takes a lot more time. Couple that with the fact I am still learning learning what the various .NET libraries do... yeah it's going to take a while.
The question is explicitly asking for information about the “Best Development tools for Upgrading from VB6.0” for a large, complex VB6/COM upgrade and second about C# or VB.NET.
A perfect “conversion” tool would help you meet the two critical goals of every upgrade
The Tool’s role in Preserving Functionality
Large, mature legacy systems can contain thousands of code files and millions of lines of code. The effort required to fully describe and verify the functionality embodied in that much code is massive. In fact, there can be so much functional work that some technical-minded teams fail to see it at first. They spend most of their time worrying about how to take advantage of the latest .NET design, language, and framework features before they fully appreciate just how difficult it will be to preserve and verify the legacy functionality. It’s like they are fishing from the back of a huge functionality whale while worrying about catching little technical fish.
Teams that try to reproduce a mountain of code by reading, interpreting, and recoding it manually may well go blind in the process… So a critical feature of any conversion tool is to help the team read, interpret, and rewrite their code while rewriting it in a form that preserves its semantics. Computer scientists have studied the problem of reading interpreting, and rewriting source code for over 60 years and the solution they came up with is called a compiler. An effective code “converter” works like a compiler.
VB6 is a high level language: the Microsoft VB6 compiler and its runtime did myriad things implicitly: managing type inference, implicit conversions, implicit by ref, late-bound calls, dealing with nulls, goto-style error handling, designing forms, etc. A VB6 converter must also be able to recognize and store the myriad little details not explicitly in the code and it must be able to correctly express those details in .NET. An industrial strength conversion tool will have a powerful, extensible VB6 metalanguage system that allows the user to control how VB6 code is recognized and interpreted.
VB6 is also easily extensible through COM. There are many hundreds of different COM APIs in use, and that is not counting all the in-house components that typically become part of enterprise systems. The converter must be able to recognize any COM class or control used by the VB6, both in UI design and in code and express it using some other appropriate .NET API or interop. One tool I know of can even generate a .NET code framework from the COM usage information in the VB6. An industrial strength conversion tool will have a powerful COM type system that is extensible and allows the user to control how COM is replaced in the generated code.
The Tool’s role in Taking advantage of .NET
VB6 and .NET are different in many ways and so are the various APIs that support the two platforms. So, with tools or without, there will almost always be some re-design required. Furthermore, each team brings different preferences, constraints, and requirements to their project: ask 10 programs how to code something and you will get at least 10 different answers. The converter must be help the team express its unique preferences, constraints, and requirements. This includes providing repeatable, self-documenting means of modifying VB6 code before it is processed, modifying .NET code after it is generated, integrating hand written code, describing custom API replacements, directing custom code restructuring, and doing many other various dynamic and project-specific transformations as required.
Putting it all together
A large upgrade is rarely fully predicted and planned in advance. Even with extensive knowledge of both the source code and the desired .NET coding standards, there will be many problems and opportunities that emerge during the work. The source code and requirements must be allowed to change during the upgrade project. What is needed is an agile methodology that allows the team to adapt to source code changes, experiment with different .NET coding techniques, respond to a deeper understanding of requirements, and incrementally improve their automated upgrade process over time. An industrial strength conversion tool will have the accuracy, precision, flexibility and speed to enable this type of methodology.
One more comment about Conversion tools. The most important ”tool” you will use in a .NET upgrade is your brain. You must learn .NET languages, design-patterns, and frameworks and apply what you know in your upgrade effort. The best automated tool does not decide for you how to rewrite your code: it helps you re-implement the legacy functionality according to the design you decide makes sense.
Microsoft suggests several tools in this article. VB6 Upgrade Partner Tools
VB.NET or C#
When I ask the .NET community (i.e. search the web) for information, tools, ideas, code, and help with programming problems, I am much more likely to find answers expressed in C# than in VB.NET. I also find the C# compiler is a better fit for a tool-assisted rewrite because it requires the generated code to be more internally consistent and explicitly described. Getting and keeping the build is a somewhat crude, but absolutely critical test of code quality and a key milestone in any upgrade effort. Remember that VB.NET is not VB6. This sounds obvious, but it can be hard to keep in mind because the two language look similar. This similarity can be deceiving; so IMO it is better to go to C# where you are reminded that the rules are different. Finally, C# has always been and continues to be designed for .NET; VB.NET cannot say that.
Disclaimer: I work for Great Migrations. There is a lot more to discuss. Please visit Great Migrations Documentation Portal for more articles and to get the gmStudio Trial and try an industrial strength upgrade tool for yourself.
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.
