Some customers have reported that VB Migration Partner crashes during the conversion of very large projects, or very large files belonging to middle-sized projects. These errors usually appear in random places but are often related to operations with the Regex and StringBuilder objects. (You can detect where the execption occurred by looking at the error log file that VB Migration Partner automatically creates in C:\ root folder when a fatal error occurs during the migration process.)

VB Migration Partner internally creates many memory-consuming structures, for example symbol table of all the members in the VB6 project being converted. We have optimized these structures, though, and in general the actual used memory is far smaller than the memory available to a .NET executable (VB Migration Partner itself is written in VB.NET.)

For these reason, we are inclined to believe that these OutOfMemory exception are caused by a less-than-perfect behavior of the .NET Framework’s garbage collection.

As all expert .NET developers know, Microsoft claims that invoking the GC.Collect() method is never necessary in a client Win32 application, because the garbage collector “knows” when it’s time for a GC. The truth is different, though. As a matter of fact, the problem usually goes away when we use a special version of VB Migration Partner that periodically invokes the GC.Collect() method.

The problem with “forced” garbage collections is that they tend to slow down execution (and this is the main reason why Microsoft discourages them), therefore we didn’t want to add a performance penalty to all our customers, because only a very small fraction of them are facing hugely large VB6 projects. The solution we adopted is to make all the GC.Collect() calls optional.

If you experience the OutOfMemory exception while converting a very large VB6 project, you must explicitly enable the GC.Collect() calls, by creating a text file named VBMigrationPartner.fixes in the C:\ root folder, that contains the following line

        AutoCollectLevel=2

If the problem still persists, then the only solution is trying to reduce the memory used by VB Migration Partner during the conversion. The following tips may be useful:

1. Convert one project at a time, rather than converting a project group.
2. Run VB Migration Partner in batch mode (vbmp.exe) instead of running the full-featured UI version.
3. Avoid using the SetTag MigrationReport pragma to create an XML report (see this KB article)
4. Avoid using AddLibraryPath pragma to alias one or more type libraries; instead, use one TypeLibImport pragma with @-prefixed argument for each type library.
5. Use DisableMessages CodeAnalysis pragma to reduce the number of emitted warnings. (If the problem persists, also try the DisableMessages All pragma and inform our tech support if this extreme measure solved the problem.)
6. Try adding a ParseMode Off pragma at the top of the longest VB6 source files.

Notice that using Disable Messages All pragma (point E) or ParseMode Off pragmas (point F) are intended only as diagnostic techniques and are useful only to identify the exact cause of the malfunctioning.

Adopt one technique at a time and check which one solves the out-of-memory problem, if any, then contact our tech support and include a summary of your findings.

----

A more radical approach to saving memory and prevending out-of-memory errors is based on the SetOption ExcludeMethodBody and the PostCommand pragmas. This approach is especially effective if the current project contains very large source files and can be helpful also to dramatically speed up all migrations after the first one.

1. Apply a SetOption ExcludeMethodBody pragma at the project level (in the *.pragmas file) and  a SetOption ExcludeMethodBody, False pragma at the top of the largest file (or files) in current project.
2. Migrate the project and fix any compile error in the largest files, by applying any necessary pragmas. Ignore all other source files, that contain only method and property signatures.
3. Once the largest files are converted correctly, manually save the resulting VB.NET files (of those files only) to a new directory that is not a subdirectory of the folder where the .NET project has been saved. (In this example we will assume this new directory is named c:\convertedfiles.)
4. Now remove the SetOption ExcludeMethodBody pragma at the project level from the *.pragmas file and change the pragma at the top of largest files into SetOption ExcludeMethodBody, True (argument was previously False)
5. Anywhere in the project insert the following pragma:
   

         '## PostCommand cmd /C copy c:\convertedfiles\*.* "${ProjectPath}"

6. Repeat the migration process, this time focusing on all files except the largest files you have already converted.

Thanks to the PostCommand pragma added, at the end of all migrations VB Migration Partner automatically overwrites those largest files with the refined and error-free version that you have saved in the c:\convertedfiles directory.