We received (and happily publish) another great feedback from one of our beta testers. The original text is in Italian, but I translated it for you here:

Thanks, CodeArchitects! And a special thank to Francesco Balena for the job he did in developing this great VB6/.NET migration tool.

Few people in this industy believed that such a product could be implemented and could have been so effective, including Microsoft who never really invested in a migration tool. Our company invested a lot of time and money on VB6 products, and we left abandoned to our destiny when VB.NET was released, together with many VB6 developers. Code Architects managed to create such a tool, thanks to their determination, perseverance, and deep knowledge of both migration techniques and VB6/VB.NET inner workings. From now on, VB6 applications *can* be migrated, at last!

We have adopted VB Migration Partner since the beginning of the beta test program, and we stressed it on large complex projects (over 110,000 lines of code) that contain both custom and 3rd-party components, ADO, intensive Windows API usage, advanced graphics, sockets, even a script compiler. We always got great results and were able to migrate our projects by just adding a few migration directives (pragmas) to teach VB Migration Partner how to behave in a few special cases.

Giampaolo Lionello
Software Development Manager
Prometeo S.p.A.: www.prometeo.com


What can I add to Giampaolo's words? I have seen their app in action and was impressed by their care for details. The most innovative detail is the presence of a custom script compiler, which allows partner vendors (and even power users) to customize every little detail of the application to fit their requirements. VB Migration Partner has been able to migrate the script compiler easily and quickly, which was quite remarkable.


Giampaolo and his team at Prometeo also provided many good pieces of advice. For example, they managed to migrate the entire data layer (about 25,000 lines) into a working VB.NET library in just a few hours. They then replaced the old VB6 data layer with the new VB.NET component and everything worked fine. There was a double jump from COM and .NET - VB6 calling VB.NET which was using ADO - yet the new data layer was only marginally slower (about 6%) than the original VB6 code. To their surprise they realized that this overhead was caused mainly by the many string concatenations inside the data layer compoment.

The obvious solution was to use a StringBuilder, but we went one step further: we added the StringBuilder6 class to our support library. This is a custom data type that looks exactly like a string (it supports the & operator) but it internally uses a StringBuilder. They were able to optimize all concatenations by just adding a few SetType pragmas. On top of that, we improved our code analysis engine to automatically flag all string concatenations inside loops and suggest which string variables could be turned into StringBuilder6 objects for highest efficiency.