Document last updated on: 18 August 2010
This document provides answers to some frequently asked questions about ASNA's Upgrade Assistant—its utility to help migrate AVR Classic Windows programs to AVR for .NET Windows programs. Check back frequently to this document—it will be updated frequently.
What is the ASNA Upgrade Assistant?
The Upgrade Assistant (UA) is a migration utility that transforms AVR Classic applications to AVR for .NET applications. The UA migrates about 95% of the AVR Classic code to .NET. For most AVR Classic applications, programmer intervention is generally required to resolve the remaining 5% of the non-migrated code.
Is .NET knowledge required to use the UA?
It’s quite common, and even rational, to assume that using the UA should be a be away to learn .NET. After all, what could be better learning experience than seeing code you know from one environment transformed to work in another environment. Alas, this isn’t the case with the UA. It is not intended to teach .NET programming. Don’t try to use it like that.
In virtually every case, .NET projects generated from the UA will require programmer intervention to get the program to compile. To be able to perform this programming, you must be at least an intermediate level .NET programmer. Successful use of the ASNA Upgrade Assistant assumes that programmers with both COM and .NET experience are available to the project. During migration, many informed decisions about the .NET code must be made—you'll need good .NET skills to make these decisions.
What is required to perform a UA migration?
You need AVR 4.1 installed with a permanent license, and AVR for .NET 9.x/Visual Studio 2008 or AVR 10.x/Visual Studio 2010. The UA is a .NET application installed implicitly with AVR for .NET and it is invoked through AVR 4.1 (the UA is itself a .NET application). Once you install AVR for .NET, your instance of AVR 4.1 will have an “Upgrade to .NET…” option on the “Projects” menu. When you migrate an AVR Classic project, the UA creates an AVR for .NET version of that project for you.
Can the UA migrate AVR 3.x or 4.0 applications?
The UA requires an AVR Classic 4.1 application as input, so you’ll first need to compile your pre-AVR 4.1 applications to AVR 4.1 before migrating them. This is generally a pretty simple step and requires little or no programmer intervention. The UA requires that you save the AVR 4.1 project as text (right-click each file in the project from the Project window and use the “save as text” option) before invoking the UA.
Can the UA migrate non-working AVR Classic applications?
While non-compiled AVR Classic programs can be migrated with the UA, the programmer intervention required to make the program work in .NET is usually quite high. We strongly encourage you get the program to compile and run in AVR 4.1 before using it with UA.
What version of DataGate does this migration require?
AVR for .NET 9.1 requires DataGate 9.1. However, his version is backwards-compatible with AVR Classic and will work with your existing AVR Classic apps. That means that the migration to .NET is non-disruptive to those AVR Classic apps that haven’t yet, or won’t, migrate.
What project types are migrated with the UA?
The UA works with Windows applications and AVR class libraries. Substantial architectural differences between the COM and .NET platforms preclude the UA migrating ActiveX control, and ASP projects. These project types need to be migrated by hand.
How are subfiles migrated?
For .NET Windows programming, .NET native the DataGridView control is the functional equivalent of the AVR Classic subfile. The DataGridView can be populated with a variety of .NET data structures, but the most frequently used structure is the .NET DataTable. In .NET, the DataGridView and the DataTable represent a very clear separation of concerns; the DataTable provides the data to the DataGridView and the DataGridView provides the presentation.
The UA recognizes this .NET separation of concerns. The AVR Classic code that populated the old subfile control is 100% migrated to code that populates a DataTable (technically, the generated code populates an AVR Memory File which internally exposes the needed DataTable). The code that manipulated the properties and events of the AVR Classic subfile is also migrated, but it’s likely to need some programmer intervention to get the code to compile. The DataGridView and the AVR Classic subfile control have very different object models and behaviors.
As a side note, the separation of concerns that .NET provides for data grids is nice because you can easily swap out different display grids (for example, you may initially target AVR for .NET’s built-in DataGridView control, but later swap it out for a more expression and functionally complete third-party grid (e.g., one with auto-column sorting or direct export to Excel). This kind of swap requires little or no change to the logic that populated the data that populates the data grid.
Does the UA support third-party controls?
Third-party controls used by AVR Classic apps are COM/ActiveX based and .NET can consume most of those controls naturally. So, in many cases, at least for the initial migration, you won’t need to migrate the third-party controls you’re using—you’ll simply continue to consume them from your AVR for .NET application.
That said, some of those COM/ActiveX controls are very old, perhaps even provided by vendors no longer in business. So third-party controls do offer a potential hot-spot for manual programmer intervention after the migration process. Note especially any third-party control that is a container control (that is, a control onto which you place other controls—such as a panel or a group box or tab control) cannot be migrated. The graph control that ships with AVR Classic is also a migration hotspot. The company from whom ASNA licensed that control went out of business; graph controls and the associated code needs to be manually migrated.
There is one third-party control issue special case: the heavily used FarPoint Tab control. While the UA doesn’t attempt to migrate this control, it does attempt to redirect AVR Classic code used against that control to AVR for .NET code. The UA recovers the controls in the tabs and positions them in corresponding tabs on the MS .NET tab control (included intrinsically with .NET). Event handler code is migrated but it’s not wired to any MS tab control events.
Note also that AVR Classic included 28 controls and that AVR for .NET includes more than 90 of them (for example, AVR for .NET includes a masked edit textbox, a tree control, a window splitter control, a rich textbox control, a month calendar, a datetime picker, and a Web browser, just to name a few). Except for all but very special case controls, it’s quite likely that AVR for .NET already offers the functional equivalent of whatever third-party controls your app uses. These intrinsic .NET controls, though, do general offer a substantially different programming API that your AVR Classic app used. Programmer intervention is required to use these intrinsic .NET controls.
A good strategy might be to try first consuming your existing COM controls with your newly-migrated .NET app. Then, change the code to exploit native equivalents as time allows.
Does the upgrade assistant support ANSA’s AVR Classic COM add-ins?
The UA provides a call-level compatible replacement for the ASNA Miscellaneous String control. This control provided string functions, edit codes, and clipboard support. Other controls, such as the OSFIle control, the File System Object from MS (FSO), and DG DB control aren’t directly supported and will need programmer intervention.
Where can I learn more about the UA capabilities?
You can learn more about some of the specific capabilities of the UA in this ASNA DevNet article.