ASNA Visual RPG for .NET :FAQs

ASNA Visual RPG for .NET Framework targets the original Microsoft .NET Framework. At this time it doesn’t support what was original called .”NET Core” and is now simply called “.NET.”

The original, formal name of ASNA Visual RPG was “ASNA Visual RPG for .NET” (recall that Microsoft’s formal name for its Visual Basic product that targets .NET Framework is “Visual Basic .NET”).  Microsoft’s renaming of “.NET Core” to “.NET” causes grief for everyone! 

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.

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 CHAIN, SETLL, and READE
• A program call implemented with CALL/PARM (which obeys argument pass-by-reference semantics)
• The library list
• QTEMP
• 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.

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—especially if the AVR Classic app used custom controls. 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.

Yes. .NET assemblies created with Visual RPG can be consumed by both C# and VB.NET, and, conversely, assemblies created with C# or VB.NET can be consumed by Visual RPG.

ASNA Visual RPG includes more than 100 controls. So it’s not likely that you’ll need any third-party controls. However, if you do, Visual RPG is compatible with nearly all third-party controls that work with C# or VB.NET .