VB Migration Partner

KNOWLEDGE BASE - Classes and COM objects


Previous | Index | Next 

[HOWTO] Avoid compilation errors caused by unsupported designers

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"
Previous | Index | Next 




Follow Francesco Balena on VB6 migration’s group on

LinkedIn





Read Microsoft Corp’s official case study of a VB6 conversion using VB Migration Partner.




Code Architects and its partners offers remote and onsite migration services.

More details




Subscribe to our free newsletter for useful VB6 migration tips and techniques.

newsletter



To learn more about your VB6 applications, run VB6 Analyzer on your source code and send us the generated text file. You will receive a detailed report about your VB6 applications and how VB Migration Partner can help you to quickly and effectively migrate it to .NET.

Get free advice



A fully-working, time-limited Trial Edition of VB Migration Partner allows you to test it against your actual code

Get the Trial




The price of VB Migration Partner depends on the size of the VB6 application, the type of license, and other factors

Request a quote




Migrating a VB6 application in 10 easy steps

Comparing VB Migration Partner with Upgrade Wizard

Migration tools: Feature Comparison Table

All whitepapers