ASNA Visual RPG Classic FAQ
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 4.x was created with what is now a very old C++ compiler. In order to achieve Windows 8/10 support, we ported our AVR 4.x project to a much newer version of MS's C++ compiler in 2012. This produced AVR 5.0. Except for a few cosmetic issues, AVR 5.0's primary change over 4.x is that AVR 5.0 supported on Windows 8/10 platforms. AVR 4.x is not supported on any 64-bit Windows 8/10 platform.
The only difference between AVR 5.0 and AVR 5.1 is that AVR 5.1 was compiled with a much newer version of Microsoft C++. AVR 5.0 was compiled with C++ 2012 and AVR 5.1 was compiled with MS C++ 2017. We didn't want to find ourselves in the position of having AVR Classic 5.x compiled with a compiler that Microsoft no longer supports.
AVR 5.0 and AVR 5.1 support Windows 8 and 10 desktops for both development and deployment.
For Windows servers, AVR 5.0 and AVR 5.1 both support:
- 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's success with the newer Windows platforms is unpredictable and intermittent. If you are using AVR 4.x products on unsupported Windows platforms we suggest you test things thoroughly after every Windows update is done to your development machine. Also please note that Windows 10 Home edition is not supported with any version of Visual RPG.
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 8 or 10 and taht 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.x on any platform is a short-term way to avoid addressing a very real problem--that will ultimately cause you lots of problems.
One of the challenges with AVR 4.x is that its ability to run on Windows 8/10 is often intermittent; that is, we've seen AVR 4.x apps that run fine on one Windows 10 machine and not run at all on another. AVR 5.x has been recompiled to work better with Windows 8 and 10. Using AVR 4.x on Windows 8/10 means you run the risk that the app could simply stop working at any time.
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.