[INTERVIEW] Yours truly on .NET Rocks!

clock May 2, 2014 16:30

A few weeks ago I had an interesting and entertaining conversation with Carl Franklin and Richard Campbell of .NET ROCKS, about VB6 migration, the effect that Windows XP retirement is having on companies that can't afford keeping their mission-critical VB6 apps on an unsupported operating system, and a lot more. Yesterday the interview went online, at this URL

Happy listening!

A new video on the Convert-Test-Fix cycle

clock November 20, 2007 10:15

Pragmas and the Convert-Test-Fix cycle is one of the most innovative features of our conversion tool. The ability to reduce the number of compile and runtime errors at each iteration through VB Migration Partner is essential in migrating complex, real-world applications.

Last weekend I prepared a video on this topic, both in Italian and in English. The two versions are basically identical and show how you can go apply the Convert-Test-Fix cycle to convert a real VB6 application, which you can download from our code samples page or directly from its original URL. Among the other techniques, the video shows how you can use a single PostProcess pragma to get rid of statements that reference DataReport objects (which VB Migration Partner doesn’t support) and how you can detect and solve runtime exceptions caused by auto-instancing variables.

The (semi)public beta test program opens today!

clock November 15, 2007 14:32

Today is a great day here at Code Architects. For the first time we are making VB Migration Partner’s beta release available to a selected number of prospecting customers here in Italy and abroad. We will use their feedback to improve the product even further and fix all residual bugs.

The beta test program isn’t public, not yet at least. We want to keep the number of beta testers small enough so that we can follow them in an adequate manner. If you think you qualify for being a beta tester, please contact us.

The need for a support library

clock November 6, 2007 00:24

When we demo VB Migration Partner to prospecting customers, one of the most frequent questions that come up is: Why does it require a runtime support library? It’s such a reasonable question, in fact, and deserves a detailed answer.

One of the first things that hit me when testing the Upgrade Wizard in Visual Studio is the abundance of the migration warnings it emits with even the simplest VB6 projects. Most of these warnings are basically like this: “This keyword/property/feature behaves differently in VB6 and VB.NET: read this help page for more information.” Alas, in many cases the help page is either missing or too generic. And if the page is not missing and is enough exhaustive, understanding it often requires an in-depth knowledge of the many subtleties of the .NET Framework. How can you explain all the nitty-gritty details of object finalization, GDI+, or drag-and-drop in one short page –to mention only three of the areas where VB6 and VB.NET differ in a significant manner?

When we began working on our own conversion tool, we were determined to dramatically cut out both the sheer number of migration warnings and the time an “average” developer would spend to fix each of them. Our reasoning is simple: if you are using our tool, chances are that you aren’t very familiar yet with VB.NET. Do you really want to set apart the actual migration job and study .NET each and every time you try to migrate a VB6 statement that doesn’t exactly behave as in VB6? Wouldn’t you prefer to have a wrapper method that hides all these differences and guarantees that the new program behaves like the old one?

The Format method is implemented very differently in the two languages, thus it provides a good example of the concept I am illustrating. The VB.NET version support neither named formats (e.g. “percent”) nor string alignments, and uses different placeholders for most values (e.g. “tt” instead of “AMPM”). As a matter of fact, you can rarely migrate a statement that uses the Format method without adjusting the pattern string. If the original VB6 application contains 100 calls to the Format method, you’ll probably spend a couple of hours just to fix the string patterns and test the result. Often even more than a few hours, because many of the differences between the two languages aren’t documented at all, therefore you have to learn them the hard way. To be honest, it took us a few days to discover all these tiny differences. Well, do you like wasting this time yourself or do you prefer using our Format6 replacement method?

But the support library does more than just providing a one-to-one substitution for language keywords and methods. For example, the way you implement the drag-and-drop feature under VB6 – either the manual and the automatic mode, as set by the OLEDragMode and OLEDropMode properties – is completely different from the way this feature works under VB.NET: member names and arguments are different, and even the sequence in which events fire is different. A developer might need hours to manually translate every single form that contains drag-and-drop code, not counting the time required to learn how drag-and-drop works under .NET in the first place.

A support library has other advantages, too. Let’s suppose that Microsoft releases a new version of Internet Explorer that makes the WebBrowser control behave slightly differently than it does today, for example it reverses the order in which the DocumentComplete and the NavigationComplete2 events fire. It could easily be a serious problem, because you have massively used the WebBrowser control in your VB6 projects and consequently in your migrated VB.NET applications.

What you do next depends on how you’ve migrated the VB6 application. If you have used a “classic” conversion tool you now need to re-test all your apps: if the change in IE does affect your code you must come up with a fix, recompile the source code, and redeploy the new executables to your customers. On the other hand, if you’ve used VB Migration Partner, you just need to download the new version of the support library and send it to your customers. Fast and clean! Basically, you are moving part of your maintenance costs to us. Can you ask for more?

The story behind VB Migration Partner

clock November 5, 2007 22:13

The story of VB Migration Partner begins in February 2006. I was reading Upgrading Visual Basic 6.0 applications to Visual Basic .NET and Visual Basic 2005, an e-book that had been just made available on Microsoft’s site. It’s a very good source of information and is a must-read if you are involved in any VB6 migration project. In fact I suggested my Italian publishing house to translate it and I wrote a preface for the Italian edition. The book is written by Artinsoft, the company who has written the Upgrade Wizard included in Visual Studio 2002 and all subsequent editions.

While progressing in reading, however, I realized that it was possible to create an automatic conversion utility capable to translate correctly most of the VB6 syntax clauses that the Upgrade Wizard fails to convert automatically. For example, I knew how to migrate As New variables that preserve the lazy-instantiation semantics they have in VB6; how to render Declare statements containing callback or “As Any” parameters; and how to initialize UDTs that contain arrays and fixed-length strings. I also had some good ideas for converting GoSub keywords, arrays with any lower index, graphic methods, control arrays, and other “impossible” statements.

Take the problem of deterministic finalization, for example. As you may know, .NET memory management – based on garbage collection - requires that you orderly invoke the Dispose method of objects that implement the Class_Terminate event or common COM objects such as ADO Recordsets and Connections.. Why can’t a conversion program insert the call to Dispose for you before an object variable is set to Nothing or goes out of scope? Dealing correctly with disposable and finalizable objects is indeed possible, and our VB Migration Partner can prove it. (More on this on a forthcoming blog post.)

To make a long story short, I came up with a working prototype in a couple of months. It included a parser, a code generator, and a support library that could handle the most common keywords and controls.  It was the evidence that the approach was promising, thus I abandoned most other activities and decided to focus mainly on the new tool. I rewrote the syntax analyzer – the most delicate portion of a conversion tool – from scratch, added code metrics and analysis features, completed the support library with new controls. Before long Marco Bellinaso joined the team and got in charge of the user interface module and of assessment features. Marco is a renowned writer and the author of best-selling ASP.NET books and of one of Microsoft’s official starter kits.

In spring 2007 we set up the test team, lead by Giuseppe Dimauro. Giuseppe is Code Architects’ co-founder as well as one of the two MSDN Regional Directors in Italy (the other being yours truly), and is also responsible for our consulting services. Since then the group has worked on hundreds of VB6 apps, stressed virtually every single VB6 feature, and tested the tool on many real-world business software from our Italian customers. The samples you can find here are just a little portion of what we’ve used in our tests.

In these two years we have bumped into some of the most weird bugs I ever faced in many years, and solved so many technical problems that range from trivial to overly complex. We learned how to convert some of VB6’s most esoteric features, such as ADO bindable classes or user controls with OLE_OPTEXCLUSIVE properties (ever heard of them?). We also realized that there are more undocumented differences between VB6 and VB.NET than documented ones. Perhaps we’d never started this project if we had known how complex it would have turned to be, but now we’re just very happy that we were so ignorant.

Welcome to vbmigration.com

clock November 4, 2007 16:10

I am writing this post when the site is open only a restricted number of beta testers, so odds are that you’ll read it only in a couple of weeks. Nevertheless, an introduction is in order, so here it is.

I am Francesco Balena, author of a few books on Visual Basic 6 and Visual Basic .NET for Microsoft Press. If you are a long-time VB developer, you might have read my articles on Visual Basic Programmers’ Journal (now Visual Studio Magazine) or attend my sessions at VS Live!, WinDev, or other technical conferences.  I don’t write as many books or speak as much as I used to, because I am more busy doing what I really like most: writing software applications.

My last project is also the most complex program I’ve written in my 25-year career. It took two years to complete VB Migration Partner, the most complete and innovative tool to migrate VB6 apps to VB.NET. I didn’t do all by myself, and in fact I could count on the support from some of the finest developers we have in Italy, and from a great and dedicated team at Code Architects.

We created the vbmigration web site to promote our tool and our services, but we also plan to offer plenty of articles and resources related to VB6 migration. We will keep a record of all the tricks and the conversion techniques that we’ve learned in these two years and that we implemented in VB Migration Partner. We want to prove you that our product is simply the best conversion utility on the market, but you can still use what we learned in your own migration projects even if you don’t use our tool.