VB Migration Partner with C# support has been in private beta for a few months: results and feedback have been VERY encouraging and we are now ready to make it available to all users!

Our last released version was 1.34, therefore this version should be 1.35, but we decided to jump to version 1.50 to emphasize the new C# support.

VB Migration Partner isn't the first or the only VB6-to-C# generator on the market, but for sure it features the most sophisticated engine for converting from VB6 to C#. Unlike our competitors, who still target older C# versions, we decided to generate C# code for Visual Studio 2010, so that we could take advantage of the many great features of this new version, such as optional parameters and the dynamic data type for seamless late-bound calls. The result is C# code that is far more concise, readable, and efficient that ANY OTHER tool that converts from VB6 to C#.

Here is a short and incomplete list of what VB Migration Partner 1.50 can do:

• converts VB6 optional parameters into either C# optional parameter or method overloads; as with all VB Migration Partner's options, you can set your preferences at the project, file, or method level, therefore you can produce exactly the code that you like most.
  By comparison, other VB6-to-C# tools can only translate optional parameters into method overloads, which typically means more code to maintain in the future.
• convert Variant and Object variables into the C# dynamic type, which means better and concise C# code that doesn't rely on clumsy and inefficient helper methods to perform late-bound calls.
  Unbelievably, two years after VS 2010 launch, our competitor still ignores that late-bound calls can and should rendered via the dynamic data type, and stubbornly generate a lot of code that relies on helper methods and Reflection to invoke a late-bound method.
• generates out instead of ref parameters if possible, thus allowing the C# compiler to generate faster method calls.
  No other VB6 conversion tool has this feature.
• converts Select Case blocsk into either switch blocks (if possible) or if..else if blocks (in the most general case); switch blocks are preferred to if..else if blocks because the C# compiler can optimize them into jump tables, whereas if...else if blocks require that a given expression must be re-evaluated many times.
  As you might have guessed, no other VB6 conversion tool can generate efficient switch blocks.
• can optionally generate method overloads to account for ref parameters that receive expressions and constant values; this feature alone dramatically simplifies the code that is needed to call the method.
  By comparison, other VB6-to-C# generate tons of temporary variables for each method call, a technique that makes the code more verbose and in some cases generates compilation errors.
• it can generate an interface implementation either implicitly (with public methods) or explicitly, which helps keeping the object model tidy and elegant.
  Other converters can only generate implicitly-implemented interfaces.
• convert an On Error Goto statement into a try-catch, with a warning if the try-catch block isn't perfectly equivalent to the original VB6 code.
  Other converters do the same, but never emit a warning.
• convert an On Error Resume Next statement into a series of lambda expressions, with you deciding whether this option is applied at the project, file, and method level.
  Other converters offer this feature only at the project level, which gives you no control about where the conversion should or shouldn't be applied.
• refactor Gosub calls into separate private methods.
  No other converter has this important feature, which VB Migration Partner has since 2008.
  
• gives you control over which .NET methods should be used instead of helper methods (defined in the support library), and where the replacement is OK.
  Other converters provide this option only at the project-level, which often leads to a behavior that isn't equivalent to the original VB6 code.
• convert from ADODB to ADO.NET, including support for server-side SQL Server cursors, thanks to our ADOLibrary.
  No other convert even comes close to this!

As if all this weren't enough, remember that VB Migration Partner 1.50 generates C# project that use our feature-rich support library, which perfectly mimics the VB6 behavior and prevents you from wasting weeks or months trying to duplicate the behavior of the application being migrated. This includes full support for graphic methods, drag-and-drop, data-binding, weird Windows API methods, subclassing, etc. What can you ask for more?

VB Migration Partner 1.50 Beta is available to all registered users, together with white papers that contain tips and recommendations for whoever wants to convert VB6 projects to C#. We are in the process of updating all our online docs.

I always have fun at browsing our competitors' website, especially when they have to explain which VB6 features they support or don't support, or when they attempt some bold comparisons with THEIR competitors (that is, us!)

For one, I can't help admiring the intentional vagueness that they often use when describing which controls their tool support. To them "supporting a control" is a binary property, it's either TRUE or FALSE.

Just to give you a concrete example, all the VB6-to-.NET conversion tools claim that they support the PictureBox control. Alas, they forget to mention that they

• don't support the PictureBox as a container
• don't support graphic methods, double buffering, and custom ScaleMode settings
• don't support DDE
• don't support drag-and-drop (neither "classic" nor OLE flavors)
• don't guarantee that all events are fired or are fired in the correct order
• ... and counting

As you look at it more closely, the "We support the XXX control" claim is void, unless you explicitly specify which features are supported, which ones aren't, and those that are supported only partially. The devil is the details, as they said, and many customers discover these details only after purchasing the software.

We believe this approach is ethically questionable and for this reason we always made the entire documentation for VB Migration Partner is available online, so no one can get unpleasant surprises AFTER purchasing our software. In addition to the manual we also make available the entire Knowledge Base, which orderly lists all known defects and limitations (and how to work around them). For sure this isn't a common attitude in the world of software, as our customers can attest.

In our quest for the highest transparency, we have prepared a long and detailed document (also in PDF format) that explains all the features as well as all the limitations of VB Migration Partner's support library, including the slightest differences from VB6, and - above all - how to work around them. This information has always been available on our website, but finally our customers have a single document that gathers the information spread in hundreds of different KB articles.

It is a safe bet affirming that all software vendors maintain a list of known issues with their tool, as we do, but you won't find this list available on our competitors' websites.... Too embarassing?

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 

Some developers may be concerned about support library and would prefer not to distribute an additional DLL with their migrated apps. This is understandable, but we believe that these concerns are negligible if compared to the many advantages that a well-written, comprehensive library gives you.

Such benefits stand out so clearly that even our competitors can’t deny that an extensive library can speed up a migration project. To counter this evidence, however, they try to convince that a library has many shortcomings. Fortunately, we can easily prove that all these “issues” are groundless, as we do in our 17 reasons for using a support library in migration scenarios whitepaper.

The point is, a comprehensive support library is the key factor in achieving 100% functional equivalence and in keeping migration time and cost as low as possible. Just read what one of our customers has to say:

“An initial migration compared migration tools from six vendors. It showed superior results for VB Migration Partner, which delivered fewer compilation and runtime errors than all its competitors… It took 2.5 hours to get a compilable and runnable VB.NET project with VB Migration Partner, and 13 hours with its closest competitor.”

The higher productivity that a complete support library gives you is a sure fact, and our competitors haven’t found yet a way to obtain different results in similar rigorous productivity tests. In the absence of objective measurements, they attempt to scare potential customers away from VB Migration Partner by making vague statements about its supposed shortcomings.

These statements never mention VB Migration Partner or Code Architects, yet the target is undoubtedly our product because we are the only VB6 conversion software vendors who use an extensive support library:

1)    …other vendors charge a runtime fee for their support library.

FALSE! VB Migration Partner users can freely distribute its library with their apps.

2)    …other vendors don’t make their library’s source code available to customers.

FALSE! VB Migration Partner users can license the library’s code.

3)    … apps that rely on a support library might not work on future versions of the operating system.

FALSE! VB Migration Partner’s library is written in pure VB.NET and uses only documented features of the .NET Framework. As such, the library is guaranteed to work on all future Windows versions that support .NET Framework 3.5 binaries.

A closer examination reveals that this line of reasoning is illogical. Just for the sake of discussion, let’s assume that Microsoft releases a Windows or .NET Framework version breaks compatibility with existing .NET 3.5 programs. In such a highly unlikely case, your own VB.NET applications will stop working correctly and the support library will be the least of your problems.

A support library actually helps to preserve compatibility. Should a future version of Windows have minor problems in running .NET 3.5 code, Code Architects will promptly fix the problem and release a new support library that all users can download for free. You’ll still have to solve compatibility problems of your main app, but at least you don’t have to worry about the support library.

4)    …other vendors may charge a subscription fee for using the library in the future.

FALSE! VB Migration Partner’s EULA states that users will be allowed to download any future 1.xx version of the library at no additional cost. Future 1.xx releases include fixes for all the problems that might be discovered in the future by Code Architects or its customers.

5)    … if your migrated apps depend on a 3rd-party library, you might be in trouble if the vendor decides to stop supporting it in the future

FALSE! VB Migration Partner’s EULA states that – should Code Architects stop supporting the product – all customers will receive the library’s source code at no additional cost. In this respect, choosing Code Architects is as safe as, or safer than, choosing any 3rd-party control, such as the grid or the report component that you might be using in most of your forms.

6)    … a support library can slow down your code

FALSE! VB Migration Partner’s library is carefully optimized and often runs much faster than the code that most VB.NET or C# developers usually write, especially if they are put under pressure by near deadlines. For example, our VB6Collection class runs many times faster than the standard VB.NET Collection object, and our StringBuilder object allows you to automatically speed up string concatenations by a factor of 100x without having you modify the generated VB.NET code.

Keep in mind that VB Migration Partner’s library has been authored by a team of expert developers, including two Microsoft Regional Directors who have written 7 top-selling Microsoft Press books on VB and .NET programming, routinely give lectures in US and Europe, and consult for Microsoft and its largest customers.

7)    …other migration tools generate inefficient code that retains its VB6 flavor

FALSE! VB Migration Partner’s conversion engine uses very sophisticated refactoring techniques and generates code that takes full advantage of VB.NET features, including Try/Catch blocks, short-circuiting (the AndAlso operator), the IDisposable interface, variable initializes, compound operators (e.g. x += 1), and much more.

Interestingly, VB Migration Partner can apply many refactoring techniques that no other VB6 conversion tool currently supports, e.g. Gosub refactoring, Declare overloads, faster string concatenations inside loops, enforcement of ByVal keyword if possible. Our competitors should think twice before drawing developers’ attention to this point.

Finally, consider that VB Migration Partner’s developers wrote Practical Guidelines and Best Practices for VB and C# Developers (Microsoft Press), perhaps the definitive textbook on this topic, and VB Migration Partner’s generates code that abides to all those rules. Additionally, VB Migration Partner is able to rename members to comply with .NET coding guidelines. If you don’t like standard .NET rules you can easily customize the rename engine by modifying an XML file. No other conversion software supports customizable rename rules.

8)    …the code produced by other VB6 converters that adopt a support library is hard to maintain

FALSE! A support library can make your migrated code more readable and easier to maintain, as I demonstrated in a previous post.

9)    …projects produced by other VB6 converters are difficult to evolve

FALSE! VB Migration Partner library doesn’t limit you in any way, because all its classes inherit from native .NET classes and you can therefore leverage the .NET Framework full potential.

10)    …you can’t mix .NET native forms and controls with forms and controls defined in a support library

FALSE! After you’ve converted a VB6 project to VB.NET using VB Migration Partner, you can extend the application by adding .NET native forms, and you can drop .NET native controls onto a migrated form. The one thing you can’t do is using a control defined in our support library in a standard .NET form, an action that would be meaningless anyway.

11)    …you can’t use Visual Studio 2008 Test Wizard to generate unit tests for VB.NET projects that use a support library.

FALSE! We describe this apparent problem – and its solution - in this KB article.

VB Migration Partner's pragmas offer a powerful and granular approach to code customization. With 70+ pragmas available, you can control virtually any single aspect of code conversion. For example you can use pragmas to:

•    correctly convert Null and Variant values
•    solve problems caused by arrays with nonzero lower bound, As New (auto-instancing) variables, IDisposable variables, etc.
•    optimize code that would be inefficient when converted as-is to .NET (e.g. string concatenation)
•    prevent subtle runtime exceptions caused by imperfect functional equivalence between VB6 and VB.NET
•    remove or comment unused or unreachable code, use Try-Catch blocks where possible, refactor Gosub keywords into calls to separate methods, and so forth
•   ... and much more.

Each pragma is described in depth in our online documentation, therefore I won't explain what each pragma does. Suffice it to say that all these pragmas allow you be in control of VB Migration Partner's code generation engine, so that you can always generate the most efficient and robust VB.NET code that is functional equivalent to the original VB6 project.

The purpose of this article is to compare migration pragmas with the customization mechanisms offered by other VB6 conversion tools.

In a nutshell, a migration pragma is a remark that you insert in the original VB6 code base or in a separate file named <projectname>.pragmas. Pragma files are very handy for copying groups of pragmas to another migration project, on the same or different computer. Pragma files even support #Include directives, therefore different projects can actually share a centralized pragma file. If you later want to add or remove a pragma from the centralized file you don't have to manually edit individual files.

The great thing about pragmas is that they can affect the entire solution/project, a single file, or an individual method or variable. This sophisticated scoping mechanism allows you to define a general conversion rule at the project-level and then mention one or more exceptions at the file-, method-, or variable-level.

VB Migration Partner is the only conversion software that supports pragmas. All other conversion tools offer personalization rules that can only work at the project level. Each rule is an all-or-nothing decision, and you can't apply a rule only to a portion of the project. As you'll see shortly, such lack of granularity can be a problem in real-world scenarios.

Let’s see a concrete example that shows how the two approaches compare to each other.

VB6 language supports Variant variables, which can contain both a scalar value - e.g. a number or a string - or a reference to an object. When migrating to VB.NET such Variant variables, all migration tools convert those Variant variables as Object variables. For example, consider the followingVB6 code:

   Sub ShowDefaultMemberValue(ByVal var As Variant)
      Dim s As String
      s = var
     MsgBox(s)
   End Sub

This method works well both when var contains a scalar value and when it contains a reference to an object, for example a TextBox control. In the latter case, the method displays the default member for the object (e.g. the Text property if var points to a TextBox control, or the Value property if var points to an ADODB.Field object.)

By default, VB Migration Partner and other conversion tools convert the above method to VB.NET as follows:

   Sub ShowDefaultMemberValue(ByVal var As Object)
      Dim s As String = var
      MsgBox(s)
   End Sub

This code works well if var contains a scalar value, but throws an InvalidCast exception if var points to an object. The reason is that the VB.NET is unable to extract the default member of an object, unlike VB6.

NOTE: VB Migration Partner and possibly other products can, in some cases, use type inference to convert these Variants into definite types such as Integer or String. Besides, VB Migration Partner is also able to use the special VB6Variant variables, for improved functional equivalence. We won't take these cases into account, because aren't important for our general discussion on pragmas.)

Let's now see how each different conversion tools can fix this problem.

VB Migration Partner supports the DefaultMemberSupport pragma, which tells the code generation engine that references to Variant and Object variables should be wrapped in a helper method that determines the object’s default member and returns its value to callers:

   Sub ShowDefaultMemberValue(ByVal var As Object)
      Dim s As String = GetDefaultMember6(var)
      MsgBox(s)
   End Sub

The GetDefaultMember6 method (defined in VB Migration Partner's support library) returns the value of the Text property for a TextBox control, the value of the Checked property for a CheckBox or OptionButton control, and so on. A similar helper method named SetDefaultMember6 is used to assign the default member of a given object that is accessed in late-bound mode.

The GetDefaultMember6 and SetDefaultMember6 methods clearly improve functional equivalence with the original VB6 code at the expense of reduced code readability and maintainability. In addition, these two methods can slightly affect runtime performance.

For these reasons, we recommend that you use the DefaultMemberSupport pragma only where one or more variables are known to contain a reference to a control or object. Conversely, if an Object variable is the result of the conversion of a VB6 Variant that can contain a scalar value, you should avoid the overhead – in both readability and performance – introduced by these methods.

Avoiding such an overhead is easy with VB Migration Partner, because its pragmas can be granularly scoped at the file or method level, and even at the single variable level. In previous example, you can leverage this granularity and associate the DefaultMemberSupport pragma only with the obj variable:

    '## obj.DefaultMemberSupport True

When such a pragma is used, only references to the obj variable are wrapped in GetDefaultMember6 or SetDefaultMember6 methods. (One pragma affects all occurrences o a given variable, or all variables defined in a given method or file.) All other Object variables are unaffected by this specific pragmas.

Conversely, because of their project-wide conversion rules, when using a converter other VB Migration Partner you're forced to pollute your entire code base with one helper method call for each occurrence of an Object variable, even if that variable can only contain a scalar value. Such a massive presence of helper method calls can have a serious impact on overall performance, readability, and ease of maintance. 

Not surprisingly, given these drawbacks, users of products other than VB Migration Partner often avoid enabling this and other project-level options, for example support for IsMissing keywod, conversion from On Error to Try/Catch, and improved support for late-bound calls.

This is a well-known problem that only VB Migration Partner's pragmas can solve in a simple and effective way.