Upgrading VB6 to C#
Is it possible to upgrade a VB6 application to a C# application in dot net?
Is the only option to upgrade to VB.NET?
Thanks in advance
R&M Technologies CC
Tel : +27 (0) 12 6616316 (w)
+27 (0) 82 4523254 (m)
Fax: +27 (0) 12 6616315
Re: Upgrading VB6 to C#
As far as I know, there's no way to convert directly from VB6 to C#, and
probably never will be -- the languages are just too different. It's hard
enough to convert from VB6 to VB.Net.
You could theoretically use the VB upgrade wizard to convert from VB 6 to
VB.Net, and then use one of several third-party VB.Net to C# conversion
utilities. (Try searching the Microsoft newsgroups through
groups.google.com with "VB C# convert OR conversion".)
However, this would be a downright ugly solution. The VB upgrade wizard
itself is a kludge -- it produces code that has a hackish quality, and
depends on the VB Compatability library (a library of functions that exist
solely for backwards compatability with legacy code.) Further, it won't be
able to convert everything, so you'll have to clean up the code just to get
it to compile. Then, after you get this code to compile, you'll have to do
a _second_ conversion from VB.Net to C#, with a second code cleanup. This
would be a mess to debug and maintain.
1. Don't convert at all. Stick with VB6 for existing applications.
2. Leave the existing code as a class library in VB6, and use C# for your
new development. The C# application can then call the VB6 procedures and
functions through COM interop. (For example, you could build a new
front-end with Windows Forms using C#, but using the legacy code for the
3. Convert your existing code base only to VB.Net, and develop new code
in C# in a second assembly. This would eliminate one step in the
translation project, plus possibly be easier to maintain. (The code would
look more like the old VB6 code.) As an alternative, don't rule out
VB.Net -- it can do almost anything that C# can do, with equal performance.
4. Rewrite the code by hand in C#, and possibly give it a good cleaning
up in the process.
Hope this helps,
"Corrie Taljaard" <firstname.lastname@example.org> wrote in message
> Hi all,
> Is it possible to upgrade a VB6 application to a C# application in dot
> Is the only option to upgrade to VB.NET?
> Thanks in advance
> C Taljaard
> R&M Technologies CC
> Tel : +27 (0) 12 6616316 (w)
> +27 (0) 82 4523254 (m)
> Fax: +27 (0) 12 6616315
There are many sites and articles -- even a 500+ page book from MSFT -- describing how to migrate and the challenges you will face. There are also about a half a dozen companies offering converters of different quality of output. But make no mistake: if you are going to migrate and ultimately maintain an application in .NET you (or your team) must learn .NET and learn it well. Before you start the upgrade, it is important to know .NET well enough that you can formulate a clear vision of how you want your application to work once it is in .NET: you have to have a good idea of where you are going before you try to get there.
Most people say "conversions do not work", so you have to "just rewrite it". Unfortunately, "rewrite" can mean just about anything, so advice to "just rewrite it" is not very helpful. Furthermore, if the application is large and complex, a rewrite will be a long, hard road and you may run out of gas before reaching your destination. Large applications have typically emerged over dozens or hundreds of person-years of development and contain thousands of intricate logic blocks, dozens of forms, and mountains of database access code that specifies the actual requirements of the application. A "Rewrite" means you will attempt to reproduce this massive specification from scratch and implement it in .NET code mostly by hand.
"Convert", on the other hand, means you admit that you can/must leverage the existing code and rather than spending time re-gathering functional specs and doing very-low-level design, you will take your working production code and put it through a process that systematically produces .NET project(s) based on your code and on your decisions for how to deal with platform differences.
The initial output of a conversion will rarely if ever build; it will also contain many subtle and not so subtle bugs; and with few exceptions, it will not take advantage of the new components and best practices of .NET. However, the converted code will be a complete, consistent .NET version of your application. It will be a familiar set of projects, forms, classes, modules, methods, and variables. This familiarity will be a great benefit to you when are debugging and fixing, and ultimately maintaining the .NET code. Also, the entire .NET codebase will be accessible through VisualStudio and many other .NET tools. VisualStudio in particular is an extremely powerful environment for analyzing, debugging, and refactoring large complex codebases and it is perfectly suited for what you must do next:
1) Iteratively debug and fix the conversion until you get to build. As you are working through this process, I recommend you keep track of the areas you plan on refactoring.
2) Begin running the app then debug and fix the conversion to address runtime exceptions. As with build issues, you keep track of the areas you plan on refactoring. I recommend you get the entire app to a point where it runs and is testable except for areas you are plan to refactor.
3) Finally comes the fun part: you fix functional defects and refactor the codebase by doing things like replacing COM components with .NET classes, and reworking your application to take advantage of .NET platform features.
One thing to beware of is that for a very large codebase, your initial translation will require a boat load of debugging and fixing and this could mean a massive amount or error prone, often tedious hand coding. However, when I said fix and refactor the conversion above, I did not mean do it all by hand. On the contrary, I meant fix the conversion process itself so that it produces more correct, refactored code that requires less and less manual fixing and refactoring. This of course means you must be using a conversion tool that can be configured to produce different (i.e. improved) outputs. These next-generation customizable translation/reengineering tools allow you to iteratively improve the translation process, and produce code that requires less manual work to finish. GreatMigrations has configurable translation tools like this.
"Conversion" does not have to mean compromise any more than "Rewrite" guarantees success and elegant code. However if done properly leveraging conversion tools will help you produce correct, maintainable code in less time and with less risk. This means you will have more time for learning the .NET language, learning the .NET framework, and learning .NET tools. This knowledge enables you to produce better designs and development processes that increase the ROI of your migration effort.
|All times are GMT. The time now is 05:23 AM.|
Powered by vBulletin®. Copyright ©2000 - 2014, vBulletin Solutions, Inc.
SEO by vBSEO ©2010, Crawlability, Inc.