Convert VB6 App to C#

[sierrasoft]

I want to convert a VB6 Application with many Forms to C# .Net 2.0. How can i do it. Is there a tool available?

[LizR]

Most of the so called conversion tools dont seem to work as well as anyone ever wants them to. Coupled with the fact you're converting a win32 app to a .net app in from a language which allows for insane amounts of sloppyness, to a highly structured one.

[ddanbe]

It will cost you more time converting then rebuilding it from scratch, believe me.

[LizR]

And the app you'd get would be worse by converting too

[mjuras]

As others have rightly pointed out, you will find things you want to change in automated translations -- much the same as you would find things to rework during a manual rewrite. Fortunately, there are some translation tools that are designed to be customized. If you invest time designing your .NET development standards and tuning the tool to meet those standards up front, you will arrive at a configuration that strikes a good balance between what you do by tool and what you do by hand -- for typical large codes (>100K LOC) the coding work can be 90-95% automated and often higher.

There is a vendor that specializes in this type of technology. This forum does not allow mentioning specifics so you will have to search the web to find them.

[ddanbe]

the coding work can be 90-95% automated and often higher.

That will you cost 5% of your time, the other 95% time (and more!) will be spent on getting right the 5% code that rests.
Been there, done that.

[mjuras]

I been there, done that too and I am not trying to understate the expertise and effort needed to migrate real world VB6 codes to .NET. But let me clarify this: I am talking about large corporate or commercial business systems: dozens or hundreds of interrelated VBPs and 100s of thousands of LOC). The source codes of these systems describe literally tens of thousands of business rules and myriad other technical details about every aspect of the application: what data is in every form/page, file, and query, how is it presented and formatted, where does it come from, where does it go, what are the rules of the calculations and transformations, and what happens if there is an error. Often you will find that the programmers and users do not fully understand what the systems do in all scenarios. That is the point of software after all: to faithfully recall and execute complex data manipulation and myriad technical operations for us.

Both tool-assisted and manual migrations demand a lot of design work to define how you will effectively take advantage of .NET. The difference is in how you spend the rest of the migration project resources. With a manual rewrite from scratch, you will spend way way more resources re-gathering requirements, manually typing in code, and fixing the defects that come along with massive amounts of new manual effort. With a tool-assisted rewrite, you will spend more time tuning the translator to produce codes that faithfully reproduce the results of the original application while fitting into the new design. I am not saying this is 100%, and I am not saying that all new code should start from a translation – select parts of the system will certainly have to be redone from scratch.

Face it: The source code is the most accurate and complete specification of what the system does and how it does it, and 99% of the time it is the only specification. Doing a rewrite from scratch means ignoring the existing source and it means you will rebuild a mountain of functional and micro-level technical requirements manually. Functional requirements gathering will end up taking the majority of your resources and that is not where they should be spent: migration work must focus on researching the new platform, creating a design to take advantage of it, and upgrading your processes and code to take advantage of it all. Leveraging tools to help you do the job, particularly when the job is to migrate huge systems, allows the team to spend their resources more effectively.

[LizR]

Except Ive yet to see a system come out of a converter that didnt need a rewrite anyway

[jbennet]

Yep. Converters are crap

But if you insist, i reccomend upgrading to vb.net first, then converting to c#

[ddanbe]

Conversion tools ALWAYS take with them the "bad" design from the past into the future. So you always have to take into consideration : What can be improved?

[mjuras]

I agree it is very difficult to write a VB6 converter; after all a "real converter" must at minimum be a VB6/COM compiler and VB6/COM is a pretty hefty platform.

I can only speak to my personal experience, and the one we used started out very crappy indeed, but we did not start trying to finish and deploy any bigger translations until we got the crap out. We worked with the vendor to custom tune the tool to our requirements so it produced correct codes and it did most of the re-engineering as well (i.e. replacing third-party COM components with .NET) . The best part was the business logic was complete and correct.

Only the most technical\messy parts of the code, that were always highly localized, needed to be rewritten by hand. Also most of the common architecture components were replaced with hand written frameworks/components that were already in production for new .NET systems we had been building. We configured the tool to make the apps use the new in-house frameworks/components as well.

We migrated dozens of VBPs and almost a million lines of code in about 18 months. The migration was done along with all the usual maintenance and projects and we saved several million USD (at least 60%) compared to what a rewrite would have cost us -- and that was just the IT cost. I have no idea what the total cost if we would have been if tried to rewrite from scratch, but I know we would have had alot more meetings with the business to gather requirements and probably spent a whole lot more cycles in test.

[LizR]

The main one is why are you changing language if you arent going to be making use of its features.

[mjuras]

You hit the nail on the head! What can be improved? That is the question! What is wrong with the current application, what *specifically* is wrong with this translation? What are the new opportunities that we *must* take advantage of in adopting .NET to get mre ROI out of this investment.

Most of the time the initial design has flaws. However I have seen a number of commercial systems (even ASP!!) that are pretty damn clean and have a sound application architecture. Software companies tend to pay attention to code qualtity. Those folks will mostly be replacing system architecture components.

Of course even hand built systems have design flaws. Refactoring rules. And that brings up another point: getting the app up and running in .NET opens the door to using the next generation refactoring, analysis, and review tools sooner. IMO, this alone makes a compelling for case conversion. Having both the old and new codes open and laid out to you in the new visual studio is much a more powerful way of wworking than having VB6 on the left and C# on the right.

[ddanbe]

Why would you keep VB6 on the left? As a backup you would never use anymore after conversion?

[LizR]

I think it was meant in terms of rather converting it by hand line by line - which of course you wouldnt, you'd convert class by class assuming the vb code even was remotely OO based in the first place.

[mjuras]

What I meant was you would refer to the original VB6 during the manual rewrite -- not after.

You can only get so much detail about what the app is supposed to do from your requirements gathering sessions -- we all know this to be true. So you will be frequently going back to find and figure the details by tracing legacy code -- remember it is the only spec for the legacy system that is accurate and complete. My assertion is that it is easier to analyze and interpret the legacy code and ultimately rewrite it (aka convert by hand) if you can also load/process/analyze it in VS2KX rather than just in VB6. Even better if you can actually build/run/debug it in C# side by side with the new C# code.

If you do the conversion right you will have no need whatsoever to open VB6 again -- old code gets stale fast anyway. But on the other hand, many IT shops opt for manual rewrite approach. They end up riding the VB6/COM-.NET fence for a long time, troubleshooting interop, developing with VB6 and VS200X side-by-side and constantly negotiating when/if to migrate each piece of their legacy codebase. Another thing folks run into with manual re-writes, assuming they do not have solid testing processes, is they find out they left out some lesser-known/used requirements after deploying the .NET and they end up going back to the VB6 in crisis mode to figure out how the missing stuff is supposed to work.

We knew this fence-riding thing was not for us and that is why we invested in 1) figuring out where we wanted to be in .NET and 2) developing a process get us there with quickly and reliably. We wanted to get the migration quickly over and standardize all teams on our new .NET based architectures and processes.

[mjuras]

I think it was meant in terms of rather converting it by hand line by line - which of course you wouldnt, you'd convert class by class assuming the vb code even was remotely OO based in the first place.

Most VB6 codes I see make extensive use of objects and many larger systems involve multiple inter-related VBPs communicating through COM.

With the tool-assisted rewrite approach the real work of migration is done in terms of re-engineering design tasks -- cross-cutting concerns really. How will we re-engineer data access, error handling, logging, configuration, security? What will our standard forms/pages look like -- how will we replace third-party COM components with .NET ones? We research these design problems and implement an approach that leveages the tools but also uses new code (built, bought, or borrowed from open source) as appropriate. The translations are typically run over and over again, each time comparing new runs with old runs and verifying that the transformations are becoming more correct and more conformant to our emerging standards. Often small test codes are created to isolate common legacy coding patterns so we can more easily perfect the translation process. We begin targetted functional testing as early as possible to find systematic functional defects in the translations. What we resist doing is trying to finish very large translations by hand untill they are "good enough".

Once the tool's configruation and any replacement components are verified "good enough", we recommend converting the entire application stack -- not line by line or class by class -- but all inter-related VBPs in one step. The tool is designed for this and makes sure the changes are done in a consistent manner and it propagates reengineering changes across all interfaces. The conversion process itself is very fast -- thousands of lines per second. So you can convert a big multi-VBP application (say 300kLOC) in about 5 minutes.

[jbennet]

you'd convert class by class assuming the vb code even was remotely OO based in the first place.

vb6 wasnt an OO language, it just had some hacks which made it oo-like

[LizR]

Exactly, so converting to a language that should be treated as OO for it is (althoguh you can semi butcher it and ignore it mostly) it would be pointless to change to c# if you werent going to be making the most of what it offered

[mjuras]

LizR,
I am not arguing about where we are going, just trying to share my opinion on different ways to get there.

I agree whole heartedly that it would be pointless to move bad VB6 code directly to .NET and just stop -- worse -- it would backfire . Systems that get too krufty and kludgey become a liability; it does not matter what platform they are on. Although I would also assert that krufty, kludgey and left to rot on a dying platform is even worse -- thats the death of hope and ultimately that is a system that no one will care to work on. You stay on VB6 too long and your good people are probably going to leave. So ultimately this becomes not a question of "if" but of "when" and most importantly "how???".

We as individiuals and teams should learn and use new the features of .NET framework, languages and tools; the new OO/Aspect/SOA/next-big-thing design pattern or framework; TDD, refactoring, agile, continuous integration and all that is good in SD. But moving forward does not mean we have to leave our legacy applications behind, we have an obligatoin to bring them with us. Nor does it mean we have to scrap them, start over from scratch, and rewrite every single line of code by hand. We captured a whole lot of hard work in that VB6 code, we should use it. Doing so will free up more time to master the new technologies and use them to get the job done.