With the introduction of ASNA Visual RPG Classic 5.0/5.1, ASNA now provides a longer-term option for the persistence of your AVR Classic applications. AVR 4.0 and AVR 4.1 are both retired and no longer receiving updates or product fixes. We strongly recommend you upgrade from AVR 4.x to AVR 5.1. Here is a list of questions and answers about AVR Classic 5.x:

AVR 5.0 and AVR 5.1 support Windows 7/8/10 desktops for both development and deployment.

For Windows servers, AVR 5.0 and AVR 5.1 both support:

  • Windows Server 2012
  • Windows Server 2012R2
  • Windows Server 2016
  • Windows Server 2019

AVR 5.x is not recommended for use with Windows Surface devices. For building apps Windows Surface devices use AVR for .NET.

Please see this Retired Version Information page for our retired products' platform support.

No, AVR Classic 4.1 requires Windows XP and AVR Classic 5.x requires Windows 8/10 for development. This isn’t a decision we wanted to make, but one that was imposed by shifting the development of AVR Classic 5.x from an older Microsoft Visual C++ compiler to the latest version of that compiler.

We do know that some users claim to be using AVR 4.x on Windows versions that we do not support. However, AVR 4.x success with the newer Windows platforms is unpredictable and intermittment. If you are using AVR 4.x products on unsupported platforms we suggest you test things thoroughly after every Windows update is done to your development machine.

No. Support for AVR 4.0 ended several years ago and support for AVR 4.0 ended with the arrival of AVR 5.1. "Not supported" means these products are frozen and won't get any more fixes or changes. We strongly encourage AVR 4.x customers to upgrade to AVR 5.1.

Microsoft stopped supporting Windows XP on April 8th, 2014. Most AVR Classic customers moved to either Windows 7 or Windows 8 prior to that date. If you are still using Windows XP please be aware that although AVR Classic apps still run on it, ASNA is no longer doing any product testing on Windows XP (we don't trust using it in our network). If you are going to continue using Windows XP, we encourage you to download and read the free IDC Windows XP risk assessment whitepaper from Microsoft. We do strongly recommend that ASNA customers stop using Windows XP as soon as possible.

Third-party controls are a potential issue. Our testing shows that many do work, at least in a runtime environment, in Windows 7/8/10. However, some customers have reported problems using them in a Windows 7 development environment. One of the problems is that most of the companies who originally offered these controls are now out of business and there simply isn’t any support available for the controls. Mabry and Graphics Server are simply gone. Sheridan was bought by Component Source and they still sell the popular Sheridan Active Threed controls, but look at the caveat towards the bottom of their Web page that says:

“Please note that this product is no longer supported by the publisher, so it is no longer eligible for product support or maintenance.”

(Translation: Component Source will gladly sell you deprecated copies of the Sheridan controls—but don’t call for support!).

The behavior of third-party controls is completely out of our hands so when controls have issues with Win 7/8/10, there isn’t anything we can do about that. Customers using third-party controls will need to test their apps vigilantly.

The company we licensed the graph control went out of business many years ago. It is no longer distributed with AVR Classic. Its possible that your old version of the graph control might work with AVR Classic, but if it doesn’t, you’ll need to find a workable alternative.

Your existing 4.x should compile with AVR 5.x just fine. Simply open the 4.x project in 5.x and recompile. Do note that upon opening the 4.x project, as in past versions, the 4.x project is converted to a 5.x project—and there is no going back on this process. Be sure to make a backup of your 4.x project to project yourself against unseen issues. Remember also that you may encounter issues that third-party controls may impose. If a third-party control doesn't work in 5.0 you'll need to find an alternative.

Ultimately, how you manage the persistence of your AVR Classic applications is up to you. We think it is very important for you to carefully consider your options and make solid, informed decisions. Several customers have told us that their AVR Classic 4.1 apps are working fine on Windows 7 and there isn’t a justification to attempt to do anything else to these apps. For mission critical (and maybe we should also say revenue critical!) applications, we think that sticking with AVR 4.1 and Windows XP/Windows 7 is a short-term way to avoid addressing a very real problem.
Investing in AVR Classic 5.x was an expensive project for us—but one that we felt was important for our Classic customers. Our discussions with customers worldwide have confirmed there are a great many AVR Classic applications still in use today, and support for them is important after April, 2014. Without AVR Classic 5.0, the viability of AVR Classic applications diminishes greatly in the spring of 2014. Yes, there are constraints and concerns in getting your AVR Classic 4.1 apps to AVR Classic 5.x, but we think they are surmountable. Especially given that for not much effort, AVR Classic 5.0 dramatically extends the life and viability of your AVR Classic applications.

It’s not the persistence of AVR Classic 5.x, specifically, that we’re worried about. It’s the inevitable timing out of the COM model that worries us. We’ve already noted the effective collapse of the ActiveX vendor marketplace. We know that Microsoft has built into Windows 7/8/10 a workable persistence model for COM applications. However, we don’t know how many more releases of Windows will continue that COM persistence model. There may come a time when Windows simply isn’t able to support the COM model—and we think strategically we should all be planning on that day. We once had a customer say to us, “I’ll worry about the demise of the COM model when MS Office stops relying on COM.” That’s a good observation—we might well be able to read into the future by watching Office closely. After all, who has more legacy COM than Microsoft? With the advent of Office 365, we think the tea leaves are there to read!

AVR 5.x is not recommended for use with Windows Surface devices. For building apps Windows Surface devices we recommend using AVR for .NET. None of the AVR family runs natively on Apple or Android devices.