VB Migration Partner supports the DataEnvironment designer, but not other kinds of .dsr classes that you can defined in VB6. Among the unsupported designers are the Data Report designer, the WebClass designer, the DHTML Page designer, and the Microsoft Forms 2.0 designer.

Unsupported designers are simply not migrated. For each unsupported designer class in the project, an upgrade issue similar to the following one is emitted at the top of the first file in the project:

    ' UPGRADE_ISSUE (#02F8): Designer 'DataReport1' can't be converted 
    (file D:\Projects_NET20\VB6 Samples\school\Reports\DataReport1.Dsr)

By default, VB Migration Partner doesn’t handle in any special way statements that contain one or more references to unsupported designers. When the converted VB.NET application is loaded into Visual Studio, each of these statements cause a compilation error like the following one:

    Name 'DataReport1' is not declared

In general, replacing an unsupported designer is a lengthy and complex operation. In the case of Data Report designers you need to migrate each report separately, for example by converting it to a 3rd party report component that is available for the .NET Framework platform. In the early stages of the migration process, however, you may prefer to hide these compilation errors, so that you can compile the VB.NET code and concentrate on the business logic. The easiest way to do so is by remarking out all the statements that contain a reference to Data Report or other unsupported designers.

You can achieve this result by adding OutputMode pragmas in the original code, as in this example:

    '## OutputMode Remarks, 1
    DataReport1.Show()

Even better, you can use the PostProcess pragma to comment out all the statements that contain a reference to the DataReport1 component. The regular expression isn’t trivial, though:

    '## project:PostProcess "(?<=\n[ \t]*[^']).*\bDataReport1", "' UNSUPPORTED: $0"

When applied to the previous VB6 code, this pragma would transform the offending statement as follows:

    ' UNSUPPORTED: DataReport1.Show()

In general you can use a single pragma to account for multiple unsupported designers. For example, let’s suppose that the VB6 application contains the following unsupported designers: DataReport1, DataReport2, and dsrReport. Here’s the PostProcess pragma that can handle all of them:

    '## project:PostProcess "(?<=\n[ \t]*[^']).*\b(DataReport[12]|dstReport)", "'UNSUPPORTED: $0"