We are very proud to announce that a new great feature will be introduced in forthcoming version 1.32.

Trace-Match is both a technical feature and a methodology to generate functional equivalent .NET application in less time and with less effort.

In a nutshell, from a technical perspective Trace-Match is the combination of the following elements:

• a VB6 trace library (VB6TraceLib.dll) that allows you to determine what method is entered/exited, the value of your variables, the contents of controls, etc. It can send output to file or to any utility that can display debug data (e.g. SysInternal's DebugView utility), profile your code, and more. It even works correctly if a method is abruptly exited if an unhandled error occurs. You need to install this library only on the computer where you do your migrations.
• a .NET trace library that works in the same way as the VB6 library. These .NET classes have been included in our main support library, therefore there is no need to distribute an additional DLL to your customers. As with the VB6 library, you can easily enable or disable tracing as it is more convenient for you.
• two new commands in VB Migration Partner, which allow you to quickly insert and remove trace statements in any VB6 project or project group.

Trace-Match gives you two priceless benefits:

Full functional equivalence: by comparing the trace files produced by the original VB6 program and the migrated .NET application, you can have an "objective" evidence that the latter is 100% functionally equivalent to the original VB6 code. All you have to do is running a set of test cases against the VB6 and .NET executables, and using a file Diff utility such as WinMerge to verify that the trace files are identical.

Integrated debug features: if the converted .NET is being used by your customers or your collegues, you might want to leave trace enabled, so that you can easily see what went wrong if they notice a malfunctioning. If everything works fine, we even provide you with a simple Visual Studio macro that can remove all the trace statements from the .NET project.

We developed the Trace-Match methodology for internal use some time ago, and since them we have successfully used it to migrate many VB6 applications for our customers. By making Trace-Match available to all VB Migration Partner users, we are sure their productivity will dramatically increase. Read our whitepaper to learn more.

... and yes, you aren't going to find this great feature in any other VB6 conversion tool on the market!

After many months of internal beta testing, last week we released our revolutionary ADOLibrary to selected customers.

As you may remember from a previous post, Code Architects' ADOLibrary offers effortless migration from ADODB to ADO.NET. Basically, ADOLibrary is a set of ADO.NET-based classes that expose an ADODB-like object model. For example, the ADOConnection object has the same programming interface as ADODB.Connection and behaves much like the same; the ADORecordset class works like the ADODB.Recordset class, and so on. ADOLibrary currently supports all ADODB classes, with the only exception of the Record class. It is important to emphasize that ADOLibrary is fully ADO.NET and has no dependency on ADODB or other COM technologies.

ADOLibrary currently supports the vast majority of ADODB features, including forwardonly-readonly rowsets, optimistic batch updates, parameterized commands and stored procedures, the Filter property for client-side recordsets. If accessing Microosft SQL Server, keysets and dynamic server-side cursors are also supported. ADOLibrary event supports most ADODB dynamic properties, such as Update Criteria and Unique Table.

Actually, it's easier to list what ADOLibrary does *not*currently support, namely hierarchical recordset, the Record object, and multiple, semicolon-separated commands in the Execute method (they are fine in the Recordset.Open method, though).

The whole ADOLibrary documentation is already available online. This is a draft version and lacks some code samples, but it is already enough exhaustive to be usable.

 

Just arrived and published in our Testimonials page. Any comment seems superfluous

Visual Basic Migration Partner from Code Architects is the product that Microsoft should have supplied instead of that dreadful Upgrade Wizard!  It is fast, efficient and informative.

However I'm going to say more about Code Architects technical support.  In my experience this is second to none and is THE model of good support that others should aspire to.

Even questions that I now see are trivial, were answered quickly, clearly and courteously.  There was no feeling of 'we are the experts and you are an idiot' that you find in some places.

The speed of reply is outstanding - normally replies come within two or three hours and often much quicker.  The answers are answers to the questions that I actually asked - it is clear that the support team has taken care to understand to read my questions.  The replies themselves are full, providing a clear course of action, and give reasons for that action and helpful background information and suggestions.

When dealing with some rather obscure aspect of the properties of a control, I came across a small problem in VBMP.  I received a correction later on that same day.  What more could you want?

In short, while using VBMP tech support I have never felt that I was going to be left dangling.

Geoff Adams
Linos Photonics

A few minutes ago we uploaded VB Migration Partner v. 1.31, which contains many interesting and useful additions, including

• Full support for Visual Studio 2010
• The new SetOption RemarkMethodBody pragma permits you to migrate only a subset of all the forms, modules, and classes in a large project, so that you can look at and solve a smaller group of compilation errors. (More details here)
• The new Troubleshooting command in the Help menu quickly brings you to a page that shows how to solve the most common problems when working with VB Migration Partner

As usual, we also fixed a few problems – most notably in file I/O commands and subtle issues related to minor differences in how VB6 and VB.NET load and unload forms.  We improved data-binding and correctly implemented the DataFormat property that all controls expose, and ensured that the Timer.Timer event works exactly as under VB6. The complete list of all the fixes can be found in the VERSION_HISTORY.TXT file.

Registered users can access the download page from within the Help menu.

Have a happy (and errorless) migration !

Today Microsoft announced Visual Studio 2010. VB Migration Partner v.1.30 already supports it.... here's an except of the official press release (which is available in its entirety here). 

Code Architects, Visual Studio Industry Partner, announced today that it will ship a new version 1.30 of VB Migration Partner, which includes support for Microsoft Visual Studio 2010. 

Since May 2008, VB Migration Partner allows developers to successfully convert their Microsoft Visual Basic 6.0 legacy applications to the Microsoft .NET Framework. VB Migration Partner supports all the main Visual Basic 6 features and controls, and allows refining the converted application while keeping it in sync with the original project, thanks to migration pragmas and proprietary convert-test-fix methodology.

[...]“Microsoft is pleased that Code Architects, a Visual Studio Industry Partner, has invested early in supporting Visual Studio 2010 and our next-generation application development platform, and is today simultaneously shipping VB Migration 1.30,” said Matt Nunn, group product manager of Visual Studio at Microsoft Corp. “Products like VB Migration 1.30 help customers simplify their development process from design to deployment when using Microsoft products like Visual Studio 2010 and .NET Framework 4.”

As our customers already knows, starting with version 1.30 VB Migration Partner can generate Visual Basic 2010 projects and solutions. In this short article I'll illustrate how you can generate code that leverages one of the coolest new features of VB2010: auto-implemented properties.

To see when and why auto-implemented properties can be useful, consider that most properties are just wrappers for a private variable, as in the following example:

Private m_ID As Long
Private m_Name As String

Public Property Get ID() As Long
    ID = m_ID
End Property

Public Property Get Name() As String
    Name = m_Name
End Property

Public Property Let Name(ByVal value As String)
    m_Name = value
End Property

When converted through VB Migration Partner, the above code generates these VB.NET statements:

Private m_ID As Integer
Private m_Name As String = ""

Public Readonly Property ID() As Integer
    Get
        Return m_ID
    End Get
End Property

Public Property Name() As String
    Get
        Return m_Name
    End Get
    Set(ByVal value As String)
        m_Name = value
    End Set
End Property

In cases like this – that is, when a property is merely a wrapper for a private variable and doesn’t perform any additional action – you can generate a new cool feature of Visual Basic 2010: auto-implemented properties. In fact, in VB2010 you can rewrite the above code block with just two lines:

Public ReadOnly Property ID As Integer
Public Property Name As String = ""

VB Migration Partner doesn’t include an explicit option to generate auto-implemented properties. However, you can easily tweak the converted VB2010 code to reach this goal. In fact, you just need three pragmas:

'## REM tranform the variable declaration into an implemented property
'## PostProcess "\b(Dim|Private)\s+m_(?<prop>Name)(?<type>\s+
        As\s+.+\r\n)", "Public Property ${prop}${type}"

'## REM same as above, but this is for readonly properties
'## PostProcess "\b(Dim|Private)\s+m_(?<prop>ID)(?<type>\s+
        As\s+.+\r\n)", "Public ReadOnly Property ${prop}${type}"

'## REM delete the Property procedures
'## PostProcess "[ \t]*(Public|Friend|Private)\s+(ReadOnly\s+)?Property
        \s+(ID|Name)\b.+\r\n(.+\r\n)+?\s*End Property\r\n", ""

The interesting point is that you need only three pragmas regardless of how many properties you want to process. For example, suppose that you have a class that contains 8 properties that can be transformed into auto-implemented properties:
    FirstName, LastName, Address, City, ZipCode, Country  (read-write)
    ID, Age (read-only)
These are the three pragmas that you need:

'## PostProcess "\b(Dim|Private)\s+m_(?<prop>FirstName|LastName|Address|
        City|ZipCode|Country)(?<type>\s+As\s+.+\r\n)",
        "Public Property ${prop}${type}"

'## PostProcess "\b(Dim|Private)\s+m_(?<prop>ID|Age)(?<type>\s+As\s+
        .+\r\n)", "Public ReadOnly Property ${prop}${type}"

'## PostProcess "[ \t]*(Public|Friend|Private)\s+(ReadOnly\s+)?Property\s+
        (FirstName|LastName|Address|City|ZipCode|Country|ID|Age)\b.+\r\n
        (.+\r\n)+?\s*End Property\r\n", ""

Cool, uh?

NOTE: If the original VB6 code accesses the private variable outside the property procedure, you need one more pragma to ensure that all references to the variable are rendered as referenced to the property

'## PostProcess "\bm_(?<prop>FirstName|LastName|Address|City|ZipCode|
        Country|ID|Age)\b", "${prop}"

Also notice that if the property is marked as ReadOnly and you access the inner variable in places other than the Class_Initialize event handler, than you can't render the property as an auto-implemented property.

 

One of the problems you have to face when converting a large VB6 project is that the resulting  .NET project can have so many compilation errors that it may take a lot of time just to get rid of all of them and be able to run and test the migrated code.

To make things worse, Visual Studio can only display 102 compilation errors in its Error List window. If your migrated project has more errors, you will see the following, quite uninformative and useless message at the bottom of the list:

Error 102: Maximum number of errors has been exceeded.    

You don't know whether your migrated project has only as few as 103 or as many as 2000 compilation errors. The only way to discover the actual number of compilation errors is fixing them until their total number goes below the 102 threshold.

The main problem with a migrated .NET project that has many compilation errors is that it might take you days or even weeks until you get rid of all of them. And because you don't know how many errors you really have, you can't have make any prediction on when you reach the zero-compilation stage. Life is unfair, uh?

The solution to this dilemma would be simple if your migration tool would allow partial or incremental migrations, that is, if it would allow you to convert only one form, class or module at a time. When focusing your attention on a single source file, odds are that it generates fewer than 102 compilation errors, thus your job as a migration developer would be quite easier, wouldn't it? In fact, many customers asked us for a way to better face the migration of "monster" projects with hundreds thousand lines of code.

Alas, all VB6 to .NET migration tools currently on the market - as well as all code conversion tools tout court, for that matter - only allow you to migrate entire projects in one single operation. This was true for VB Migration Partner too, but things are going to change very soon.

In fact, starting with forthcoming versoin 1.31,  VB Migration Partner users can perform partial migrations and incrementally convert a large VB6 project one form, class, or module at a time. Even better, it will be even possible to migrate one method at a time, if you feel like it! Let's see how the mechanism works.

VB Migration Partner 1.31 supports a new pragma that forces our code generation engine to remark out all the executable statements inside any method that falls inside the pragma's scope. For example, let's say that you are converting a very large VB6 project that causes too many (hundreds? thousands?) compilation error to be listed in Visual Studio's Error List window. Instead of attempting a complete conversion, you decide to initially focus on just the main form of the converted application.

First and foremost, you add a project-level SetOption pragma that states that all executable statements inside all the methods in the entire application have to be remarked out:

   '## project:SetOption RemarkMethodBody, True

If you migrate the VB6 project now, you would obtain an "empty" VB.NET project, that presumably will compile correctly because it contains only the method and property signatures. For example, here's a converted method would look like:

Public Function DoubleIt(ByVal x As Single) As Single
    ' EXCLUDED: Dim res As Single = x * 2
    ' EXCLUDED: Return res
End Function

Next, let's start focusing on the application's main form, which is contained in the MainForm.frm file. To do so, just add the following file-level pragma at the top of such a file, to re-enable the usual way of converting to VB.NET:

   '## SetOption RemarkMethodBody, False

If you now re-convert the project, you'll see all (and only) the compilation errors caused by incorrect statements inside the MainForm.vb file. Notice however that the VB.NET compiler won't cause any compilation errors for statements that reference methods in other files - for example the DoubleIt function - because the signatures of those methods have been included in the converted project. They are empty and won't do anything if invoked, but at least they don't cause any compilation errors.

Once you have fixed all the compilation errors inside MainForm.vb you can turn your attention to another file. (It is essential that you apply your fixes exclusively by means of pragmas, so that your fixes will be preserved when you re-convert the project).

For example, you might want to focus on the Helpers.bas module that contains the DoubleIt function. You can do so by simply adding the following pragma at the top of the Helpers.bas file:

   '## SetOption RemarkMethodBody, False

Interestingly, the SetOption pragma is granular down to the method level, therefore you might even decide to focus on one method at a time. To do so, just type the pragma inside the method itself:

    Sub Test()
       '## SetOption RemarkMethodBody, False
       ...
     End Sub

If you don't want to re-convert the entire project each time you fix all the errors in a given form, module, or class, you can just use Visual Studio Find & Replace command to uncomment the remarked statements. In fact, all such statements start with the ' EXCLUDED string, therefore you just need to replace this prefix with a null string. You can do that for all the excluded statements in the current file, the current method, a group of methods, and so forth.

NOTE: it's important to notice that the remarked VB.NET statement is the migrated statement, not the original VB6 statement. Therefore, when you unremark one or more methods you end up with the same VB.NET code that VB Migration Partner would have produced if you used no SetOption pragma. 

Unremarking a single method or all the methods in a file using Find & Replace is a matter of a seconds, therefore you might prefer this approach to re-convert the entire project. However, we strongly recommend that you apply your fixes exclusively by means of pragmas (as opposed to manual fixed to the .NET source code), because this approach complies with our convert-test-fix methodology and gives you a lot of many other advantages.

Partial and incremental migrations at the file (or method) level is a concept that no other conversion tool has ever supported, and probably will ever support for some time. While other tool vendors are still attempting to match other VB Migration Partner's great features - for example migration pragmas and our convert-test-fix approach to migration - we just lifted the bar a bit higher.

We just published an interesting comment from one of our customers in the Testimonials page (the boldface is mine):

 

We just received a very nice comment from our customer, and I couldn't help quoting it:

I must say at this point I am incredibly impressed with the software, tried other products and got a half baked application that ran in loops.  With VB Migration Partner I had a running prototype the same day.  This is the best spent money we have ever experienced.  Thanks and good luck with the product.

Jeremy Pethick
Mazeppa AS 

I was especially pleasured with it not just because our customer choosed VB Migration Partner after comparing with other VB6 migration tools that have been on the market for years, but also because it demonstrates that, in spite of all its power VB Migration Partner is as easy-to-use as it can possibly be.

 

The most recent beta - more precisely, a release candidate - of Visual Studio 2010 has been released only a few days ago, yet VB Migration Partner already supports VB.NET 2010!

Support for VS2010 isn't the only great new feature in VB Migration Partner v. 1.30. For example, you can now generate more detailed batch reports, that contain all the main project metrics (in addition to migration warnings and compilation errors, as it happened in previous versions). We also support Shape controls with rounded corners and have refined the algorithm used to draw lines whose BorderWidth is greater than 1.

And as usual we have fixed a number of minor bugs, as reported from our customers, especially in the file I/O area. Converted VB.NET apps are now even more compatible with existing VB6 programs, and in fact they can share text and binary files with each other.

As usual, registered customers can download the new 1.30 release by means of the command in the Help menu.