One more customer praising the convert-test-fix approach

clock January 24, 2011 16:28

We received from a German customer these notes, which we gladly (and proudly) publish. As usual, boldface is mine:

On today’s market you have to be able to deliver new application versions at any time. Customers don’t accept statements like: “Sorry, we are in a migration process. We can’t add the feature you need. We can’t even fix a bug within the next year.” VB Migration Partner is the only tool which enables us to enhance the application during the migration process.

It was soon clear to us that the library approach is the way to go. VB6 and VB.NET are too different. It’s not possible for a machine to close this gap. Without VB Migration Partner we would have ended up implementing our own library. The "pragma" concept enables us to run the migration and as a result get .NET code we can compile. With pragmas migration is an ongoing process. We migrate, make changes on the generated code, express these changes in terms of "pragmas" and migrate again. During these migration cycles we are still able to change, enhance and deliver the old VB6 application. VB Migration Partner is a software which gives you the feeling the developers work with it themselves. They know the problems in migration processes and they offer solutions that work.

Conclusion: If you have unlimited time, money and manpower it might be worth having a closer look on the VS built in migration tool. If one of these resources is limited you choose VB Migration Partner.

Martin Gerhold
Dietrich’s AG / Germany

Some customers ask us whether it is feasible to migrate to .NET without a support library. This customer found the answer by himself: the support library is the only reasonable mean to automatically deliver code that runs correctly. In fact, he says that without VB Migration Partner they would end up building their own library. Fortunately we at Code Architects have spent many man/years to extend and fine-tune our library, thus you can focus on less boring facets of the business.

Equally interesting is that this customer realized that only VB Migration Partner is able to convert VB6 apps that are being modified during the process: this is the methodology we know as “convert-test-fix”. All other conversion tool work on a snapshot of the VB6 codebase, and when the migration seems to be completed you suddenly realize that you still have to re-sync your migrated code with the new features and bug fixes that have been added to the original VB6 code in the meantime.

Not really smart, uh?...but this is how all other VB6 conversion tools work.Wink

You can read more comments from actual VB Migration Partner users in our Testimonials page.

A library for all .NET developers, free!

clock January 20, 2011 17:12

David McCarter, from, has released a new version of his open source .NET library, containing a lot of useful classes and methods. This new releases includes new features and bug fixes.

You can download it from here.

[HOWTO] Leverage naming conventions to assign a specific type to implicitly-declared variables

clock January 14, 2011 09:27

One of our customers came up with the following question:

I have some code in my project that was developed by a person used to Fortran naming conventions. In his code, variables starting with letters I to N are meant to be integers while others are Double. Ideally, there would be a pragma such that we can indicate that undeclared variables starting with letters I to N are to be declared as integer while other undeclared variables should be declared double. Is this possible?

The short answer to this question is that the original developer could have used the DefInt and DefDbl VB6 directives to force the type of all undeclared variables. Adding these directives just before migration wasn’t an option, however, because they might introduce very subtle bugs if the developer failed to adhere to the naming rule in some cases. Also, the approach based on Defxxx directive can’t be applied if the naming convention is based on multiple-character prefixes, as such “int” for integers and “dbl” for Double.

Even though VB Migration Partner doesn’t provide a pragma that perform the requested task, what our customer asked for is quite in reach for it. In fact, if you use the DeclareImplicitVariables pragma, then all variables that weren’t explicitly declared are rendered as “Object” variables and are prefixed with 05B1 warning “The xxx variable wasn’t declared explicitly”. Thanks to this detail, using a PostProcess pragma to replace the variable type isn’t hard at all:

'## PostProcess "(?<=05B1\): The '(?<name>[I-N].*?)'.+\r?\n\t+Dim )\k<name> As Object( = Nothing)?", "${name} As Short", True, False, ""
'## PostProcess "(?<=05B1\): The '(?<name>[A-Z-[I-N]].*?)'.+\r?\n\t+Dim )\k<name> As Object( = Nothing)?", "${name} As Double", True, False, ""

If the developer used the “int” and “dbl” prefixes, the pragmas become:

'## PostProcess "(?<=05B1\): The '(?<name>int.*?)'.+\r?\n\t+Dim )\k<name> As Object( = Nothing)?", "${name} As Short", True, False, ""
'## PostProcess "(?<=05B1\): The '(?<name>dbl.*?)'.+\r?\n\t+Dim )\k<name> As Object( = Nothing)?", "${name} As Double", True, False, ""

Just another example of how super-flexible our VB Migration Partner can be Laughing