Visual RPG for .NET FAQ
These frequently asked questions and answers address general issues about ASNA Visual RPG for .NET. If you'd like to ask a question not listed here, please use this site's "Contact Us" form.
AVR for .NET has worked with Visual Studio for .NET since the very early days of .NET with Visual Studio 2003. We provide tech support (which includes bug fixes) for the current version of Visual Studio and the one that precedes that version.
|AVR version||Visual Studio version|
|AVR for .NET 12x||Visual Studio 2013|
|AVR for .NET 14x||Visual Studio 2015|
|AVR for .NET 15x||Visual Studio 2017|
AVR for .NET works with any commercial version of Visual Studio, including Ultimate, Premium, Test Pro, and Pro. Read about the various versions of Microsoft Visual Studio.
However, in addition to the commercial versions of Visual Studio, Microsoft also provides, for free, the Microsoft Visual Studio Integrated Shell. This is essentially a stripped-down copy of Visual Studio that doesn't include any Microsoft language support. AVR snaps nicely into the Integrated Shell.
Don't confuse the Visual Studio Integrated Shell with Visual Studio Express. That is a free, lightweight version of Visual Studio that does include Microsoft language support. Visual Studio Express doesn't support the use of third-party languages.
AVR provides a very faithful implementation of nearly all of RPG's idioms (eg, record level access, data structures, and externally described files), so the mechanics and syntax of AVR's dialect of RPG are usually quite simple for any RPG coder to learn. Within two or three weeks, a typical green-screen RPG programmer should be familiar with AVR's basic RPG operations.
AVR for .NET, like VB.NET and C#, is an object oriented language. Therefore, learning the more advanced aspects of AVR is dependent on the student's knowledge of object oriented programming. A cracker-jack VB.NET or C# coder will quickly (within a week so), be able to map his or her OOP knowledge to AVR. However, someone without any OOP experience will probably need three or four weeks to reach a high level of intermediate knowledge of AVR's OOP operations.
AVR for .NET does include an AVR Classic Upgrade Assistant that bootstraps the port of an AVR Classic Windows project to an AVR for .NET project. There are many differences between AVR Classic's COM programming model and AVR for .NET's programming model. Therefore, the Upgrade Assistant isn't an automatic application conversion facility; rather the Upgrade Assistant does the basics to convert an AVR Classic project into an AVR for .NET project. Once this project conversion is done, there will most likely be some code remediation necessary. The amount of remediation necessary depends primarily on the sophistication of the original AVR Classic app and how many third-party controls it uses.
Using the Upgrade Assistant effectively requires a thorough knowledge of AVR Classic, AVR for .NET, the .NET Framework, and the business logic in the application being ported. If you're interested in porting an application from AVR Classic to AVR for .NET, please let us know. We have several resources available to help.
VB.NET and C# don't have any direct affinity for the IBM i, its record-level access model, or RPG idioms; AVR has all of that. So, the short answer to the question is that because of AVR's built-in IBM i affinity, it is a better choice for .NET programming for an RPG programmer than VB.NET or C# is.
AVR can do nearly all that VB.NET and C# can do, but only AVR does those things from an RPG point of view. AVR is purposefully designed to be easy for an ILE RPG/RPG III programmer to learn. For example, AVR supports IBM i/RPG idioms such as:
- RPG indicators
- Externally described files and data structures
- Direct access to data areas
- RPG built-in functions
RPG file IO opcodes such as
A program call implemented with
CALL/PARM(which obeys argument pass-by-reference semantics)
- The library list
- File members
- CPF-based error messaging
Beyond those RPG-centric features, AVR and ASNA DataGate also offer superb job pooling. This means that when you use AVR for Web applications, you can expect very high scalability (ie, a single IBM i job in that environment can handle many users. You can expect to be able to route 20-30 users, and often more, with AVR browser-based applications.
In addition to its RPG personality, AVR can directly consume .NET Framework components just like VB.NET and C# can. This means that in addition to record level access into the IBM i, you can also use AVR to connect through objects in the .NET Framework's System.Data namespace. This provides AVR with SQL database connectivity through ADO.NET, for example. A typical use case of this may be to have an AVR program connect concurrently to your IBM i but also connect to MySQL or SQL Server through ADO.NET.