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.