VB Migration Partner

Bugs that drove us crazy

Francesco Balena — Wed, 25 Jun 2008 00:02:00 -0700

We all know that writing software requires a vast assortment of skills and, above all, a lot of patience. You usually need the latter to feel comfortable when you realize that you've wasted hours and days over someone else's bug. Here's the story.

Like many commercial applications, VB Migration Partner has a splash screen. No big deal. VB Migration Partner is written in VB2005, therefore we could use VB.NET application framework. As a matter of fact, defining a splash screen in VB.NET is as easy as selecting an item in a combobox in the Application tab of the My Project designer.

During the beta test period a few users reported that at times VB Migration Partner threw an exception at launch, immediately after closing the splash screen. We never managed to reproduce the problem on our computers. Fortunately the exception occured quite rarely. Until a user running Windows 2000 reported that he was seeing the exception at nearly every launch. After installing VB Migration Partner on Windows 2000 in our lab, we could indeed verify that we had a problem.

It took a while to find out that we weren't the only ones suffering from this issue. As a matter of fact, Microsoft recognizes that it is a VB.NET bug. Fortunately, they also offer a workaround. According to whis workaround you must create an invisible form from inside the Form_Load event of your splash screen, something like this:

   Private Sub Form_Load(ByVal sender As Object, ByVal e As EventArgs) _
          Handles MyBase.Load
     Dim frm As New Form
      frm.Opacity = 0
      frm.ShowInTaskbar = False
      frm.FormBorderStyle = FormBorderStyle.None
      frm.Show()
      Return frm
   End Function

Unbelievably, this code makes the problem vanish away! You can find more details in this Microsoft KB article.

We realized that *all* applications written in VB.NET could suffer from this issue, thus we added a method to our support library, named SplashScreenBugFix6, which creates the invisible form for you. You just need to add an InsertStatement pragma in the original VB6 splash screen form, so that a call to this method is automatically generated anytime you convert the VB6 project:

    ' in the VB6 project
    Private Sub Form_Load()
      '## InsertStatement SplashScreenBugFix()
      ' more code in the Load event
   End Sub

Neat tricks for smooth migration of calls to Windows API methods

Francesco Balena — Thu, 12 Jun 2008 21:13:00 -0700

VB Migration Partner does a superb in dealing with Windows API calls. Here's a summary of the features that it supports and that are out of reach for the Upgrade Wizard included in Visual Studio 2005/2008:

converts As Any parameters, by creating all the necessary overloads
deals correctly with API methods that take a callback address (e.g. EnumWindows, EnumFonts)
provides recommendation about the .NET object/method that can effectively replace the API method; we cover 300+ different API calls. (Enterprise Edition only)
in a few cases, it automatically replace API calls with calls to the corresponding .NET object/method
ensures that string immutability doesn't prevent the VB.NET code from working correctly (see this article)
generates the correct MarshalAs attributes for elements in Type (Structure) blocks
correctly translates fixed-length strings inside Type blocks, so that they work correctly when passed to the Windows API method
automatically initializes static arrays inside Type blocks, so that you don't get unexpected crashes when invoking an API method that expects to find a buffer there
creates a wrapper method that ensures that orphaned delegates don't cause an unexpected runtime exception, an advanced programming technique discussed in this KB article (Enterprise Edition only)
includes the VB6WindowsSubclasser class that helps you correctly migrate subclassing-based techniques (as explained here)

In spite of all these innovations, there are cases when you still need to manually edit either the original VB6 code or the converted VB.NET. This happens, for example, if the original code uses the VarPtr, StrPtr, or ObjPtr functions to pass memory pointers to an external API method. These three functions aren't supported under VB.NET and there is no simple way to simulate them.

The good news is that in the vast majority of cases you don't need to deal with memory pointers under .NET, because the .NET Framework offer a valid "pure" alternative to the API method in question. In this article I'll illustrate how you can take advantage of VB Migration Partner features to reduce manual edits to the very minimum and take advantage of the convert-test-fix methodology.

For simplicity's sake, let's focus on one of the simplest API methods, the GetSystemDirectory Windows API. Here's a piece of VB6 code that displays the system directory path:

    ' Main.Bas module
    Public Declare Function GetSystemDirectory Lib "kernel32.dll" Alias "GetSystemDirectoryA" _
        (ByVal lpBuffer As String, ByVal nSize As Long) As Long

    Sub Main()
        Dim buffer As String, length As Long, windir As String
        buffer = Space(256)
        length = GetSystemDirectory(buffer, Len(buffer))
        winDir = Left(buffer, length)
        MsgBox winDir
    End Sub

The first step is in refactoring this code so that you make all the Declares private and move them to another BAS module, that exposes them by means of standard VB6 methods. (If you usually write tidy and maintainable VB6 code, odds are that you have already taken this step.)

    ' This is the APIHelpers.Bas file
    Private Declare Function GetSystemDirectory Lib "kernel32.dll" Alias "GetSystemDirectoryA" _
        (ByVal lpBuffer As String, ByVal nSize As Long) As Long

    ' returns the Windows directory
    Public Function SystemDirectory() As String
        Dim buffer As String, length As Long
        buffer = Space(256)
        length = GetSystemDirectory(buffer, Len(buffer))
        SystemDirectory = Left(buffer, length)
    End Function

The code that actually displays or otherwise uses the Windows directory path is now simpler. Notice that we explicitly include the module name (APIHelpers) in the method call. This tip reduces the odds that another method with same name exists elsewhere in the project, but the technique explained later works even if you don't include such a name:

    ' the Main.Bas module
    Sub Main()
        Dim windir As String
        winDir = APIHelpers.SystemDirectory
        MsgBox winDir
    End Sub

At this point you have a VB6 project that works exactly like the original one, but it is better organized and structured, with all Declares statements gathered in one single module. Let's see how to migrate this code to VB.NET and get rid of all dependencies from non-NET code.

First and foremost, we prepare a VB.NET module that exposes the same methods as the original APIHelpers.bas but doesn't use any Declare statement. Here's how we can render the SystemDirectory function using native .NET calls:

    ' This is the APIHelpers.vb file (VB.NET)
    Module APIHelpers
        Public Function SystemDirectory() As String
            Return Environment.SystemDirectory
        End Function
    End Module

Next, we use an ExcludeCurrentFile pragma to exclude the APIHelpers.bas VB6 module from migration process and we use an AddSourceFile pragma to add the APIHelpers.vb VB.NET file to the converted Visual Studio project. The neat result is that the code in Main now calls the .NET version of the method, which doesn't use any unmanaged calls:

    ' This is the APIHelpers.Bas file
    '## ExcludeCurrentFile
    '## AddSourceFile "c:\vbnet\modules\apihelpers.vb"

    Private Declare Function GetSystemDirectory Lib "kernel32.dll" Alias "GetSystemDirectoryA" _
        (ByVal lpBuffer As String, ByVal nSize As Long) As Long
    ' ... remainder of module as before...

This solution works great, but we can improve it. In fact, a (minor) problem is that the resulting VB.NET code still uses wrapper methods and doesn't look like the "native" .NET code that an experienced VB.NET developer would write. Fear not, because all you need is a project-level PostProcess pragma:

    ' This is the APIHelpers.Bas file
    '## ExcludeCurrentFile
    '## project:PostProcess "(APIHelpers\.)?SystemDirectory", "Environment.SystemDirectory"

Notice that I dropped the AddSourceFile pragma because you don't need the wrapper method any longer (at least in this simplified example). Using similar techniques you can provide a .NET equivalent for most methods that require API calls under VB6, including methods that take arguments.

One of the long-terms goals we have in Code Architects is to apply these concepts on a larger scale to create VB6 helper modules and their corresponding VB.NET versions, to help all VB6 developers to easily migrate their API-intensive applications. Just stay tuned, as usual!

VB6 Bulk Analyzer, a command-line tool to explore multiple VB projects

Francesco Balena — Wed, 11 Jun 2008 04:26:00 -0700

We routinely spend a lot of time at our customers' site, to help them in their migration needs. If you haven't written an application's source code, understanding what the migration challenges are is a difficult and time-consuming process. It gets quickly much worse if the application is scattered over dozens or hundreds VB6 projects, as is often the case with N-tier (DNA) Visual Basic applications. In such cases, even getting a broad idea of how large the application is, how many forms it has, which controls it uses, and which technologies it relies on is a nightmare. On top of that, if the application is really huge, few people in the company (if any) have a 360° view of the entire application.

For this and other reasons, this week I decided to lock my office door and build the VB6 Bulk Analyzer tool. It's a simple command-line utility that gathers a lot of information about all the VB6 projects and source files inside a specified directory tree and then creates a concise but quite thorough report. You can download the beta build here.

Using this tool is quite easy: just open a command window, move to the root of the directory tree that contains all the VB6 source files that you want to parse, and run the utility. I will show the name of the files being processed, and then a summary of all the code it has parsed. If you parse more than a few dozens files, odds are that the relevant information will scroll away from the window, but you also have a permanent copy in the file named VBAnalyser_Report.txt, in the current directory. The tool supports a few options too, such as /quiet for omitting file names, /out to select a different report file, and /help to display a short explanation. You can also specify multiple folder names, in case your source code is scattered in directories that don't have a common root, as in this example:
VB6ANALYZER c:\firstapp c:\secondapp /out:c:\report.txt

The report file contains much useful info, including:

number of projects and source files, grouped by type
statistics about the source code (code lines, empty and remark lines, etc.), number of methods, properties, etc.
statistics about ActiveX classes (grouped by their Instancing property, number of MTS classes, etc.)
all the type libraries used in all projects, with how many times the typelib is referenced
names of all used controls and components, with a count beside each control
list of all the Declare definition, with number of occurrences of each declare
list of problematic keywords (GoSub, On...Goto/Gosub, VarPtr, ObjPtr, StrPtr, etc.), with number of times the keyword is used
list of problematic data types (Variant, fixed-length strings, etc., with number of times the keyword is used
list of problematic control properties, methods, events (e.g. members related to classic Drag-and-drop or DDE)
list of problematic constants (e.g. adOpenDynamic and adOpenKeyset means that a piece of ADO code can't be easily ported to ADO.NET)
list of COM classes that are instantiated via CreateObjects
list of OLEDB data providers explicitly mentioned in a connection string

VB6Analyzer is quite precise, especially if you consider that it doesn't really interpret the VB6 source code. It uses plain regular expressons, yet it doesn't suffer from "false matches" (eg. a keyword that appears in a remark or in a quoted string). Regular expressions make it very fast: on a 3GHz system it analyzes over 600K characters per second, or nearly 9,000 lines per second.

Please keep in mind that this build is just a beta version which I rolled out in a couple days. Please write me if you find any problem or inconsistent result.

PS: if you are interested in our VB Migration Partner or our migration services, just run VB6 Bulk Analyzer on your project and then send its report from the Contact Us page.

Feedback from the beta test trenches

Admin — Mon, 02 Jun 2008 18:05:00 -0700

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.

What are your options to survive in the next decade?

Admin — Thu, 29 May 2008 01:51:00 -0700

Well, I really mean "what are the options to have your VB6 application survive in the next decade?". After nearly 30 years in the field - I started my Computer Science studies in 1979, go figure! - many of which spent consulting for companies in Europe and United States, I have seen many tecnology revolutions, including the advent of IBM PC and of Windows 1.0. Each one thaught me a little piece of experience.

Let's quickly see the alternatives.

1) DO NOTHING (AKA "IF IT AIN'T BROKE, DON'T FIX IT")
If the application is at the end of its life cycle, for example because it doesn't fullfil a widespread need any longer, you might decide to have it die of a natural death. There is no reason to invest in a dying creature, therefore you might stay with VB6 and just fix some major bugs when your users complain aloud. Don't add any new feature or extend it in any way, because it would be too expensive too.

2) EXTEND THE VB6 APPLICATION USING COM INTEROP AND THE FORMS INTEROP TOOLKIT
In this case you leave the main application in VB6 but extend it by invoking .NET components using COM Interop, or display .NET forms using Microsoft's Forms Interop Toolkit. Version 2.0 of this add-on is a major improvement, as it even supports hosting of .NET controls inside VB6 forms. Best of all, the toolkit is fully supported by Microsoft and comes with full source code. [Thanks to Rob Windsor for remainding me of this option, see comments]

While the toolkit is free, adopting it has some obvious and hidden defects and costs, though. First and foremost, this approach isn't really a solution to the problem, is more of a technique to soften the migration path and lessen its impact on your organization. If you need to migrate because your app doesn't work well under Windows Vista, or because it's slow, or because you don't want to rely on a language that Microsoft doesn't support any longer, using COM Interop and the Forms Interop Toolkit is just a way to postpone the time when you truly need to find a reliable solution. Second, the communication between the VB6 and VB.NET portions of the application is often awkward and leads you to inefficiencies (due to COM Interop) and complex roundtrips that don't make your code easily maintanable.

The bottom line: you should use the Forms Interop Toolkit only in the bigger picture of a phased migration (as Rob suggests in this comment). That is, while a group of developers is working on the porting from VB6, another group is already extending the application using VB.NET. Before taking this approach, you should compare it with the effort required by migrating it to VB.NET in one step using a *good* migration tool (ours, that is :-) )

3) CONVERT TO VB.NET, USING THE UPGRADE WIZARD AVAILABLE IN VISUAL STUDIO
Why not giving it a try? it's free! While your hard disk spins for hours trying to convert your real-world business app, you can have enough time to google for less-then-gentle comments about this tool from the VB community. Let's skip to next option.

4) CONVERT TO VB.NET, USING VB MIGRATION PARTNER
Using our conversion tool to migrate to VB.NET makes sense in many cases. First, when the original application works well and is thoroughly tested, but needs to be extended with new features and implementing these extensions with VB6 would be too difficult or expensive. Second, when the application is so large that rewriting it from scratch would require a very intensive test phase. Third, if time-to-market is essential to beat your competition and make your existing users happy. In these cases you can leverage VB Migration Partner higher speed and precision (as noted by our beta testers)

5) CONVERT TO VB.NET, USING ANOTHER 3^RD-PARTY TOOL
There are other VB6-to-VB.NET migration tools on the market. Choosing a conversion tool is a critical decision, so you might want to ask our competitors for a trial version and compare it with our VB Migration Partner. Please do it! Please compare its feature, precision, and speed with VB Migration Partner and then let us know. If you don't have time to waste, however, ask yourself the following questions before considering another conversion tool:

a) how many VB Migration Partner's feature does this tool support? for example, does it fully support all 60+ VB6 controls, drag-and-drop, graphic methods, arrays with any LBound, Gosubs, As New semantics, IDisposable objects, As Any parameters and callbacks in Declares, etc.
b) are there any significant features that this tool support and that VB Migration Partner doesn't?
c) why they don't make their entire documentation available online before you buy?
d) why don't they dare to publish real-world VB6 apps and the VB.NET code that their tool generates?

As far as we know, Code Architects is the only vendor who has uploaded dozens of VB6 code samples and the corresponding, converted VB.NET project, to let potential customers see and test the VB.NET applications we produce. We don't upload artificially-conceived tiny VB6 projects that highlights the tool's strengths and hide its weakness. Instead, our code sample section gathers open-source VB6 projects taken from the Internet, and we guarantee that we edited neither the original VB6 code (which is in fact downloadable from its original URL) nor the converted VB.NET.

Now ask yourself: why no other vendor took this obvious step to show the world how powerful their tool is?

6) MANUALLY RE-WRITE IT TO VB.NET
In some cases, manually re-writing the application to VB.NET is a viable solution. Well, let me be absolutely honest on this point: in (very) few cases, this is the solution we recommend to our customers. If the application is a huge amount of contorted spaghetti code, has a orrible architecture and a ugly user interface....well, in this case you don't want to spend more time and money on automatic porting, because you would also port these issues to VB.NET.

When weighing a complete re-writing from scratch against automatic porting, you should take several factors into account, including:

a) rewriting often takes from 50% to 90% of the time and money that was necessary to write the original application. (Sorry, no official statistics on this, just our field experience...)
b) you need a team of developer who are experienced in both VB6 and VB.NET, and they also need to be familiar with issues related to the specific application, therefore you can't simply hire them from outside your company
c) how do you cope with continuous edits/improvements to the original VB6 code during the months required by the rewrite? In other words, can you count on something similar to our convert-test-fix methodology?
d) can really you afford the extra time required by a complete re-write? what will your competitor do in the meantime?

7) MANUALLY RE-WRITE TO C#, JAVA, OR ANOTHER LANGUAGE
I heard that a few ISVs are taking this path. In my opinion this is an irrational decision, often motivated by the anti-VB (or even anti-Microsoft) feeling that is so fashionable today. Let me explain why you shouldn't even think of jumping from VB6 to any .NET language other than VB.NET.

Rewriting a complex VB6 application into a different language has all the drawbacks of rewriting it to VB.NET (see point 6), plus the many problems that you have when switching from VB.NET to C# or Java. How do you implement On Error Resume Next in C#? How do you render a DTPicker control in Java without carefuly mapping each and every property, method, and event? But the decisive argument is: do you have enough developers who are equally familiar with VB6 and C# or Java and the application being migrated?

Briefly stated: taking this route is a technological suicide similar to point 1), except it takes longer, costs more, and is more agonizing. You can only hope that your competitors are in love enough with C# or Java to invest their energies in this option. If you hear that they are doing it, relax and be happy: you don't have anything to worry about for a long time :-)

8) CONVERT IT TO C# USING AN AUTOMATIC CONVERSION TOOL
Come on! To get an idea of how tough this "solution" (so to speak) is, take all the issues listed at point 5) and multiply them by all the problems mentioned at point 7). Then double the result to have a more reasonable estimate of the actual cost and effort.

More seriously, just think of this: there are a few commercial tools on the market that can automatically migrate VB.NET to C#, for example Instant C# or C-Sharpener for VB. I have actually used a couple of these tools, they do a great job. However, they still require a few manual edits after the conversion, to adjust minor differences between VB.NET and C#. The main reason is that the resulting C# code doesn't look like native C# and requires some fixes to be more readable and easily maintainable.

Before your consider this approach, ask yourself two questions:

a) if you believe that automatic conversion between two .NET languages (VB.NET and C#) is difficult, how can you expect that a tool be able to automatically convert from VB6 to C# in one single step?
b) on the other hand, if you think that conversion from VB.NET to C# can be fully automated, why not going from VB6 to VB.NET using our VB Migration Partner (or another tool, if you prefer) first and then using Instant-C, C-Sharpener for VB, or another similar tool for doing the final move to C#?

If you really want a C# app as the final deliverable of your conversion efforts, keep in mind that jumping from VB6 directly to C# doesn't give you more than switching from VB6 to VB.NET first and then from VB.NET to C#. Well, it actually does give you something more.... many more headaches, for precision's sake :-)

A great .NET Logging tool

Admin — Wed, 28 May 2008 21:01:00 -0700

Dennis Gurock is the main developer of SmartInspect, a .NET, java, and Delphi logging tool. I heard about this software some time ago and was impressed by its features, especially the ability to filter messages and find subtle bugs. Had I discovered it before, I would have surely used it during the test phase of VB Migration Partner, and I would have save a lot of time and many headaches. Maybe in the next coding project...

I was pleased to see that Dennis heard about our tool too, and blogged about it. I already already left a comment to thank him, but I was especially intrigued by the question at the end of his post: are there better alternatives than migrating VB6 to VB.NET than an automatic migration tool, such as migrating to Delphi?

First, my hat off to Delphi. It has been the very first "pure" object-oriented programming language that became mainstream, when C++ was just used like a "better C". Many of the best features in .NET have their roots in Delphi, therefore I highly respect this language and those who write great apps with it. It's a pity that Borland made a few faux pas and isn't the great company it used to be 20 years ago.

That said, I don't see why VB6-ers should move to Delphi instead of VB.NET. For a more articulated answer, read my next post.

Amazing feedback from a beta tester

Francesco Balena — Sat, 24 May 2008 20:42:00 -0700

Yesterday we received this comment from one of our early beta testers. I must share it with you:

After 15 years of developing our application in VB3, VB4-16 bit and VB6, I was disappointed to discover that we could not move to VB.Net. Our application was too large to rewrite into the new syntax. In spite of edits made to follow the new rules, such as omitting the lower bound on Dim statements, the migration tool available ran for 5 hours and gave 1947 errors to fix; and that was just on our main application program. Using VB Migration Partner, we converted that same code to .Net in 9 minutes and had 3 compilation errors to fix, all having to do with a third-party OCX. After commenting out those lines, the application started up and ran just fine, displaying dialogs that invoke our VB6 COM servers to perform calculations and print reports. Amazing! We need to keep developing our code in VB6 for our current clients, but the batch processing and code-test-fix methodology will allow us to convert a changing code base without making the same changes twice, once in VB6 and again in VB.Net.

ASC has been providing this application to businesses for over 25 years and we have successfully migrated from the mini-computer platform in the past. A rewrite would be impossible with an application such as ours that has evolved over so many years. Our client base has grown steadily during that time, and now includes 100’s of small to midsized firms with networks of 5 to 30 concurrent users of our application, and 20 of the top financial institutions in the nation, two of which have over 100 concurrent users of our application. With this tool, we will be able to support our existing platform and roll out a VB.Net version with minimal disruption to our clients.

Brian Olson
Actuarial Systems Corporation, USA

We knew our tool was more accurate than other tools on the market, but Brian’s experience is simply amazing: With just a few pragmas, they had a running .NET application in less than one hour!

Brian told me they are now working on details, such as inter-program communication – their VB6 app used DDE, which isn’t currently supported by VB Migration Partner – but most of the migration has been completed… in one fifth of the time it took the “other” migration tool just to parse the VB6 project

Now, that means fast!

Comment from a Microsoft MVP

Francesco Balena — Fri, 23 May 2008 03:26:00 -0700

Now that VB Migration Partner is out, we can disclose a few comments from our beta testers. Here’s the one coming from Lorenzo Barbieri (LinkedIN profile). Lorenzo is arguably the most active Italian blogger, writes on several magazines (including Italian edition of MSDN), speaks at international conferences, and is a very active MVP. Yesterday he blogged on VB Migration Partner; his post is in Italian, but I have translated it for you here:

VB Migration Partner 1.0 has been released

Today version 1.0 of the tool Francesco Balena has been working on together with Code Architects Team has been released.

In past months I have tried a few beta releases, however – because of the recent job change [In April Lorenzo joined Microsoft as a Developer Evangelist, F.B.] – I didn’t manage to test it thoroughly enough to provide useful feedback. Nevertheless, all the tests I run it through were successful and all the projects I submitted to it were converted at the first attempt.

If you still have VB6 projects and want to convert them to VB.NET, I warmly recommend to give this tool a try.

Alive and kicking: VB Migration Partner 1.0 has been released!

Francesco Balena — Thu, 22 May 2008 00:38:00 -0700

Seven months after the launch of the http://www.vbmigration.com/ web site - and about two and a half years after we wrote a first prototype - we are excited to announce that VB Migration Partner 1.0 is finally available.

True, it took a bit longer than we expected. Our beta testers reported a few elusive bugs, that we promptly fixed, but above all they give us hints and suggestions on how to improve our tool. As a result, we added many new pragmas, support for batch migrations, optimized execution for n-tier applications, include files, advanced code analysis techniques, and much more. We now support Visual Studio 2008 and the integration with Microsoft Team System. We wanted to write the best conversion tool from VB6 and VB.NET, and we did it.

In these months VB Migration Partner has proven to be a very flexible tool, able to fit the most demanding migration needs. It is being used to migrate VB6 projects of all kinds and sizes, from graphical games to mission-critical bank and insurance software, from little utilities to "monsters" business apps that count over 10 million lines. One of our customers is using it convert an interpreter for a custom programming language.

Along the way we learned more ways to improve the quality of migrated code and expanded our knowledge base with dozens of articles, which explain how to achieve the most from this tool. The great thing about VB Migration Partner is its flexibility (provided by pragmas) and its open architecture, which allows you to be in control of how VB.NET code is generated, how to convert forms containing 3rd party controls, and more.

The "convert-test-fix" methodology has been welcome by all our customers, especially those who have large "legacy" applications to take care of, that can't simply be thrown away when the VB.NET version is ready. As a matter of fact, one of our customers is planning to keep both the VB6 and VB.NET versions in sync for at least one year, until they complete the conversion and all their users have switched to the .NET version. To ensure that the two versions are "functionally equivalent" at all times, they will use batch migration and custom-made plug-ins that leverage VB Migration Partner's extensibility model. Just another evidence of how flexible our tool is.

Many developers wrote us and asked about our licensing policy. Our goal was to make VB Migration Partner a viable solution for software companies of all sizes as well as individual developers and smaller software shops. As a result, we are offering VB Migration Partner in two editions:

VB Migration Partner Professional supports the vast majority of the features described on our Web site and can convert VB6 projects of up to 50,000 executable lines. (Empty lines and remarks aren't included in the count, but lines at the top of .frm files are.)
VB Migration Partner Enterprise is the full-featured version, can migrate larger VB6 projects, performs more sophisticated code analysis and refactoring, supports batch conversions and Microsoft Team System, and is the preferred choice for N-tiered applications. Users of the Enterprise Edition can purchase additional user licenses and the full source code of the support library.

Unfortunately, at this time we can't offer a demo version that is freely downloadable, but we plan to remedy in the future. If you need to test our tool against your VB6 code, let us know.

All VB Migration Partner users benefit from a subscription period, during which they are allowed to download all the releases that have produced in the meantime. The subscription period is 3 months for the Professional edition and 6 months for the Enterprise edition.

Finally, we are launching the Early Adopter Program (EAP): for a short period you can purchase VB Migration Partner and double your subscription period: six months for the Professional edition and one year for the Enterprise edition. Start converting your VB6 applications right now and protect your investment at the same time!

Find more information on our web site.

Release 0.98 has been just released

Admin — Fri, 25 Apr 2008 08:16:00 -0700

Yesterday we worked hard to fix a subtle bug related to project groups, plus other minor stuff related to the Data and TabStrip controls.

Today is a nationa holiday here in Italy, but our beta testers abroad can download version 0.98 and play with it during the weekend. (We know for sure that some do! )

Version 0.97 is online!

Admin — Mon, 21 Apr 2008 05:09:00 -0700

This is truly a milestone in our release story. We have added many new features, including support for Visual Studio 2008 and for batch migratons. A number of KB articles describe how to use these new features, for example

[HOWTO] Generate Visual Studio 2008 project

We have added many new pragmas:

PreInclude and PostInclude pragmas allow you to include a piece of VB6 code (before the parsing step) or a piece of VB.NET code (after the migration is completed); they even support recursive inclusion (an include file can contain other PreInclude and PostInclude pragmas). The PreInclude pragma can be used in a *.pragmas file and in practice allows you to have all these *.pragmas file reference the same settings stored in a centralized file.

The OutputMode pragma now supports an Uncomment mode, which allows you to includ a block of remarked out VB.NET code and have it un-remarked during the migration process. (It is a great way to include large pieces of VB.NET code in the middle of a VB6 source file.) You can find an usage example here:

[HOWTO] Exclude portions of VB6 code from the migration process and replace it with custom VB.NET statements

We changed the way we deal with Empty and Null values. In previous releases, these values were migrated to VB6Empty and VB6Null constants, and both of them were set equal to Nothing. Using constants was necessary to support Null and Empty values when they appear as default values for optional parameters, as in this statement

Sub Test(Optional x As Variant = Null)

However, using constants didn't make it possible to map the null value to DBNull.Value, and a few beta testers complained about this. Thus we decided to map these values to Empty6 and Null6 properties, which by default are equal to Nothing and DBNull.Value, respectively, but can be changed if necessary. You can find more details in this article:

[HOWTO] Deal with Null and Empty values

Another minor improvement on previous releases: we have added the VB6Config class that gathers all the settings that you can change at runtime to fine tune the library's behavior, as explained here:

[HOWTO] Determine whether unsupported member throw an exception at runtime

[HOWTO] Ignore fatal error at runtime

The new VB6Config.FocusEventSupport lets you work around a key difference in how VB6 and VB.NET deal with LostFocus and Validate events:

[INFO] Controlling the LostFocus and Validate event sequence

We are including a new extender that allows you to create a text file containing the list of all the migration issues and warnings. It's a precious feature when you migrate multiple projects in batch mode. You can read more details in this article:

[HOWTO] Create a report with all the migration issues and warnings

We also added a few KB articles that illustrate non-obvious way to use PostProcess pragmas, for example:

[HOWTO] Modify project-level options in VB.NET programs

[HOWTO] Enforce project-level Option Strict Off settings in VB.NET programs

Last but not the least, we have fixed 35 bugs. As usual, beta tester can find the complete list in the VERSION HISTORY.TXT file.

New great features are on the way...

Admin — Tue, 15 Apr 2008 19:49:00 -0700

While we are still busy on release 0.97, I want to let you know in advance what we working on.

First and foremost, VB Migration Partner now supports both Visual Studio 2005 and Visual Studio 2008. You have to change a line in the beta's configuration file to enable VB2008 support, but it won't be necessary with the "real" product, because we plan to deliver two distinct versions of release 1.0, each one generating different flavors of Visual Basic projects.

Another great new feature is the support for batch migrations: you can run VB Migration Partner via a command-line tool and integrate it in your build process. If your application consists of dozens of separate projects, this feature can save you a lot of time and efforts. Even if you don't use a build process, you can automate the re-migration of the entire application by means of a plain batch file.

We have added a tab to the Tools-Options dialog box, where you can select a default output folder for converted projects. Not really an amazing feature, yet something that is quite handy when converting a multiple-project application.

Another simple but useful feature: project GUIDs are preserved when re-migrating a project that had been migrated previously. If you wonder why this can be useful, just imagine the following scenario. You migrate projects P1 and P2 to VB.NET (separatedly), then you launch Visual Studio 2005/2008 and create a solution S1 that gathers the two project. (Creating a single solution can be useful for debugging purposes, for example.) If you find a bug in P1 you can now re-migrate it without breaking the S1 solution, because the link between a solution and its projects depends on the project's GUID stored in the *.vbproj file. Ditto for references between projects in the same solution. It's a tiny feature but a great time saver.

Finally, we have changed the Excel template used to generate assessment estimation of time/cost of the migration process. You can now use your own formulas to define how the cost grows when the number of occurrences of a given issue grows. Thanks to this new feature you can create more reasonable migration plans.

Version 0.97 is arriving in a few days. Beta testers, stay tuned! .... and thanks for your precious support in these months.

Version 0.96 available to beta testers

Admin — Sat, 22 Mar 2008 02:21:00 -0700

We have just uploaded version 0.96. There are very few new features, namely

the SendToBack pragma allows you to finely control the z-ordering of controls
he MoveControlOverButton special method of the Toolbar control makes it easy to remedy to the fact that the .NET toolbar can't work as a control container (unlike the VB6 toolbar)
VB Migration Partner now correctly migrates the Command Line string that you set in the Make tab of the Project Properties dialog box

Of course we've also fixed several bugs, most of which related to the MaskEdBox control and the DAO/RDO data controls. More details are available in the Version History.txt file.

We are quickly approaching version 1.0, which we plan to release in mid-April. The beta test program officially ended some weeks ago, we apologize that we had to reject all subsequent requests.

Play battleship with VB Migration Partner!

Admin — Tue, 11 Mar 2008 23:07:00 -0700

We found a very nice VB6 sample, that allows two opponents to play battleship from two different computers, even across the Internet. The program consists of a server portion and a client portion, and the two use the Winsock control to communicate. The VB6 code uses also a lot of graphic statements to implement a nice user interface.

Thanks to VB Migration Partner, it took us only a few minutes and some pragmas to convert this game to VB.NET.

You can find the result in our Code Sample section. Enjoy!

One step closer to release 1.0 !

Admin — Thu, 06 Mar 2008 00:31:00 -0700

Last night we released version 0.95. It doesn't add any new feature, yet it is an important milestones because this version has reached the zero-known-bug stage for the parser & code generation engine. We are quickly fixing all the known problems in the support library and are getting closer to the official 1.0 release.

The new parser & code generator is truly as sophisticated as it can possibly be. Here's a little example of what version 0.95 is able to do.

Consider the following statements:

    Dim tw As New TextboxWrapper
    ....
    tw.FieldBox = Form1.Text1    ' where FieldBox is defined in TextboxWrapper.cls as a property that takes and returns a TextBox control

According to standard VB6 rules, the lack of the SET keyword should imply that you are assigning the default Text property of Form1.Text1 to the default Text property of the control referenced by the FieldBox property. As a matter of fact, the Upgrade Wizard that comes with Visual Studio (as well as previous versions of VB Migration Partner) translate the above assignment as follows:

tw.FieldBox.Text = Form1.Text1.Text

However, one of our beta testers discovered the following undocumented VB6 behavior: if the FieldBox is (mistakenly) defined by means of a Property Let procedure (instead of Property Set), then VB6 performs an object reference assignment even if the SET keyword has been omitted. Never head of it previously! However, we want to promote VB Migration Partner as a "It just works!" code migrator, therefore we decided to emit VB.NET code that perfectly mimics the original VB6 behavior:

tw.FieldBox = Form1.Text1 ' in VB.NET this is an object assignment

I am not mentioning this feature because I think it will be of interested to many VB Migration Partner users, but only to emphasize that our code translator is easily the most sophisticated you can find anywhere...

Together with version 0.95 we are releasing a new code sample, named Cool ProgressBar. It's a custom control written in VB6 which, as its name implies, implements a better, eye-catching progress bar, with gradient colors and other intriguing features. It's a nontrivial piece of code that uses a lot of Windows API and GDI programming, yet it took us just a few minutes (and 4 pragmas) to migrate it correctly to VB.NET. Even if you don't care about VB Migration Partner, you can download the code sample to see how those features were implemented and - if you wish - use this new control in your .NET apps.