Announcing VB Migration Partner 1.10 - the refactoring release!

clock September 21, 2008 10:26

We released VB Migration Partner 1.0 in May and the product has been an instant success, thanks to its great features that were long waited for by all VB6 developers wishing to move to the .NET world. In these months we have fixed some residual bugs but, even more important, we took note of all the requests from our customers. The result is the brand-new VB Migration Partner 1.10 version, which introduces many new features that help you to produce better and faster VB.NET. For this reason we have internally dubbed it as the refactoring release.

code migration that just works

GoSub refactoring
VB Migration Partner has always fully supported the conversion of the Gosub keyword, by interspersing the code with additional labels and a simulated return stack. This approach guarantees perfect functional equivalence with the original VB6 code, but admittedly delivers VB.NET code that isn’t very readable.

VB Migration Partner 1.10 goes further by letting you convert Gosub into call to separate private methods, i.e. the same kind of refactoring a skilled developer would perform. The private method receives all the parameters it requires, and these parameters are passed with ByRef if the callee actually modifies them.

We are very proud of this exciting feature. No other migration tool on the market supports anything similar, as far as we know. You can enable it by means of the new ConvertGosubs pragma, which can be scoped at the project, file, and method level.

Once again, we privilege functional equivalence over “beautiful” code, therefore the pragma has no effect if the Gosub can’t be refactored correctly, such as when the method contains one or more Resume statements or the target label is also referenced by a Goto or On Error statement.

Structured Exception Handling (SEH)
While VB.NET fully supports the On Error and Resume keywords, it is true that VB.NET programmers should use Structured Exception Handling (SEH) and the Try-Catch block whenever possible. You can now use the UseTryCatch pragma to have perform the substitution automatically. The pragma can be scoped at the project, file, and method scope, therefore you can precisely state where you want it and where On Error statements should be left in code.

The conversion isn’t possible in some cases – for example, if the method contains multiple On Error Goto statements or if the statement appears inside a conditional block (e.g. If or Select block) – thus VB Migration Partner performs the conversion only if the functional equivalence between VB6 and VB.NET can be fully preserved.

Type inference
VB Migration Partner 1.10 is capable, in most cases, to correctly deduce a less generic data type for Variant local variables, parameters, class fields, functions and properties. For example, if a Variant local variable is always assigned a floating point value, it can be automatically rendered as a Double variable instead of a more generic Object variable.

The new feature is enabled by means of the new InferType pragma. Like all other pragmas, you can set the scope for this action to the entire project, a specific file, or a given method, therefore it’s quite easy to decide exactly where type inference should be used. You can decide whether to limit type inference to only the members that lacks an explicit “As” clause or extend it to all Variant elements.

Unreachable code and unused member removal
Since its early betas, VB Migration Partner included a sophisticated code analysis engine that was able to spot both unreachable code (e.g. the code that immediately follows an Exit Sub statement, unless the code begins with a label referenced by a Goto o Gosub) and unused methods and properties. Developers could then decide to manually remove the code in question, to make the converted VB.NET project leaner and faster.

The new 1.10 version adds two pragmas – RemoveUnreachableCode and RemoveUnusedMembers – which eliminate the need for any manual action. Both pragmas let you specify whether the code in question should be completely removed or just commented out, therefore you can easily make your simulations and check whether the removal would have any consequence of your code.

Please notice that the code analysis engine might mistakenly flag as “unused” a method that is actually invoked via late-binding. You can quickly realize if this is the case, and if so you can use the MarkAsReferenced or MarkPublicAsReferenced pragmas to let VB Migration Partner know that the method shouldn’t be touched. (These pragmas have been available since early beta versions.)

If merging
VB Migration Partner has always supported the selective replacement of And/Or keywords with AndAlso/OrElse, but this feature had to be performed “semi-manually” by including a proper LogicalOps pragma.

VB Migration Partner 1.10 is capable of analyzing nested If blocks and decide whether it is safe to merge two nested If blocks into a single block whose condition concatenates the individual conditions by means of the AndAlso keyword. This feature is enabled by means of the MergeIfs pragma and you decide whether to scope it at the project, file, or method level. (In general, using project scope is always safe, therefore you can just place this pragma in the master VBMigrationPartner.pragmas file.)

There is no limit to the number of Ifs that can be automatically merged by this feature.
Naming guidelines enforcement
Since version 1.0, VB Migration Partner has allowed users to rename any member in the converted VB.NET by writing an extension DLL. However, in the forthcoming version 1.10 we made things even simpler by supporting rename rules stored in an XML file in a very simple syntax.

This new feature is enabled by means of the ApplyRenameRules pragma, which lets you specify the path of the XML file that holds the rename rules. We provide an XML file that contains the standard .NET naming guidelines and that you can extend or modify to match *your* guidelines. (Don’t forget that Giuseppe Dimauro and I are the authors of Practical Guidelines and Best Practices for VB.NET and C# Developers, thus we know what we are talking about.)

For example, a typical naming guideline might dictate that all push buttons should have a name with “btn” prefix and that any other prefix – such as the “cmd” prefix, often used in VB6 – should be dropped off. A guideline isn’t restricted to forms and controls, though, and you are in controls of how VB Migration Partner should rename variables, methods, fields, properties, parameters, and so forth. You can even decide to restrict rules to certain project items.

And yes, if declarative XML isn’t enough flexible for your renaming requirements, you can still implement custom rename rules using any .NET programming language.

Support for Infragistic’s ActiveThreed Plus library
Many VB6 applications use one or more SS** controls, namely SSCommand, SSOption, SSCheck, SSFrame, and SSPanel. These controls were originally included in earlier Visual Basic releases to support features such as 3-D effects. More powerful versions of those controls were later gathered by their manufacturer – Sheridan, and then Infragistics – into a commercial library named ActiveThreed Plus.

Not only does VB Migration Partner support all the original SS** controls that were included in Microsoft Visual Basic, it also supports other controls in the ActiveThreed Plus library, namely SSResizer, SSScroll, SSRibbon, and SSTransition. (It doesn’t support only two of the 11 controls included in the library: SSSplash and SSSplitter.) Notice that these controls are supported by means of fully managed .NET controls and you don’t need to deploy the original ActiveX controls with the converted VB.NET application (but you need the original controls when running the migration process.)

Preserve your investement! VB Migration Partner users can adopt the convert-test-fix methodology and solve all compile/runtime errors exclusively by means of pragmas and without any manual intervention on the generated VB.NET. This means that they can leverage all the new refactoring features by simply adding the new seven pragmas to the master VBMigrationPartner.pragmas file, and restart the migration process. With VB Migration Partner it's that simple! Laughing

That’s all for now, but I will post more details in the future. VB Migration Partner 1.10 will be released and made available to registered users in a couple weeks.

Learn about VB6 Migration at VSLive! New York

clock September 2, 2008 10:57

On Wednesday, September 10, 1:45 p.m. I'll speak at VSLive! New York and give a session entitled "Tricks, Traps, and Techniques in Migrating VB6 Applications to .NET" . Here's the session abstract:

Six years after Microsoft launched the .NET Framework there are just too many VB6 business applications waiting to be ported to the .NET world. Given the limitations of the Upgrade Wizard, not surprisingly many software shops decided to go through the long and costly process of rewriting their applications from scratch or – much more frequently – just to stay with VB6. Unfortunately, some 3rd party ActiveX controls don’t work well under Microsoft Vista and Microsoft has officially discontinued tech support for VB6 in March 2008. This has made upgrading to .NET the only option for VB6 legacy apps.

In this session we’ll briefly list the most important issues you have to face when migrating your VB6 code to VB.NET and how you can solve them. We’ll briefly cover all the most evident differences between the two languages – data types, arrays, structures, error handling, and so forth – and then dig under the surface to reveal many undocumented details, for example how string immutability and orphaned delegates can make your converted VB.NET code fail. We will also illustrate many examples of how you can use a support library to shorten the distance between VB6 and VB.NET and reduce the time you spend testing the converted code, how to work with arrays with non-zero lower bound, how to simulate control arrays, how to use regexes to fix common problems in the migration process, and much more. Attendees will receive the source code of a support library that implements all the techniques discussed in the session (a trimmed down version of a commercial support library used in real-world migration projects).

if you happen to be attending VSLive!, you're welcome...

Version 1.00.06 released

clock September 1, 2008 10:19

We just made version 1.00.06 available to all registered users. We didn’t add any new pragma in this version, yet it includes some important improvements:

First, VB Migration Partner now connects to our Web site and informs you whether a new version is available. To reduce overhead, this check is performed only at the first launch in the day. No more fear to be using an outdated version…

Next, we made the deployment of migrated VB.NET apps much simpler than before, in that you don’t need to distribute the following DLLs even if the project uses the corresponding ActiveX control or technology: InetCtlsObjects.dll, MSCommLib.dll, MSMAPI.dll, MSScriptControl.dll, MSWinsockLib.dll, RDO.dll, MCI.dll, MSACAL.dll, MSChart20Lib.dll, MSDataGridLib.dll, MSHierarchicalFlexGridLib.dll, AxVBLibraryOCX.dll.

Finally, VB Migration Partner now supports DAO 3.6 (previous versions used version 3.51). This change might cause a compilation error if your VB6 code uses the RepairDatabase method. You can work around this issue by using the CompactDatabase method instead, as explained in this KB article.

We also fixed one dozen bugs. As usual, all the details are available in the Version History.txt file.


Follow Francesco Balena on VB6 migration’s group on


VB Migration Partner - Subscribe to our feed RSS  blog RSS
AddThis Feed Button

Home blog
AddThis Social Bookmark Button


Sign in



<<  May 2017  >>




Microsoft Regional Director
Microsoft is a registered trademark of Microsoft Corporation in the United States and other countries and is used under license from Microsoft

My programming tools

VB Migration Partner


My books

Programming Microsoft Visual Basic 6

Programming Microsoft Visual Basic 2005: The Language

Practical Guidelines and Best Practices for Microsoft Visual Basic .NET and Visual C# Developers