Skip to main content

Run Practical .NET Applications on IBM i Using Mono

This open-source development allows users to run .NET applications on IBM i.

Code in white green and pink on a black screen.

If you’ve been following recent developments, you’ll notice that IBM i has made significant strides in open-source support. From PHP early in the 2000s to R introduced in 7.4, developers have many choices in what to use for new development. However, one option notably missing in the portfolio has been a way to run .NET programs on IBM i, and developers have been waiting for years to have it.

The wait is finally over. Mono, an open-source implementation of the .NET Framework, has been ported to IBM i. While this port is still rough around the edges, you can run practical .NET applications on it, and people I’ve talked to have expressed interest in it; some doubted .NET on IBM i would ever happen until now. 

What makes this development so interesting is that it didn’t come from IBM, but from the open-source developer community. I’ve been developing this port since January 2018 with a lot of help from developers from the upstream Mono project, IBM i users and IBM employees involved with open source. So much of what I’ve done and learned from wouldn’t be possible without their expertise and assistance. There’s a lot of potential for more long-desired software to come to the i this way, as its open source community grows.

Trying out Mono

If you’re interested in trying out Mono, you can check out the website for Mono on i. If you haven’t already, you should get YUM, which is the future of getting open-source deliverables such as PASE on IBM i. Once you have YUM installed, you can get Mono through adding an additional YUM repository, which provides extra software to install. Once you’ve added this repository, you can install Mono by adding the mono-completepackage; this can be done from IBM i Access Client Solutions, or by SSH. Additional support for Visual Basic or System.Drawing is installed by the mono-basicand libgdiplus0packages.

After installing Mono, you can verify its functionality by compiling a simple C# program and running it with Mono. You can put the contents of this file, which is a simple C# program, and run the mcscommand over SSH. This will create an .exefile, that you can run with the monocommand. This transcript from an SSH session should provide an example of this:

# Change the current directory to the one where the file is.
$ cd /home/calvin/csharp
# The cat command will print the contents of the file.
$ cat hello.cs
using System;
class HelloWorld {
      public static void Main () {
            Console.WriteLine ("Hello world! You are running {0}", Environment.OSVersion);
# The mcs command will compile this C# file into a .exe
$ mcs hello.cs
# The mono command will run .NET executables
$ mono hello.exe 
Hello world! You are running Unix

Alternatively, instead of compiling on IBM i you can compile from Visual Studio or another environment. Likewise, you can do the opposite and compile on the i and run the compiled program on your own system instead. The cross-platform development abilities Mono provides can be very useful for providing a comfortable developer environment all while having the applications run on multiple systems.

Mono supports ODBC the same way as .NET on Windows does, so you can use the new ODBC driver for IBM i to access databases. Just change the connection string as needed, and you can reuse the same database code.

Unfortunately, there are some deficiencies in the port. Some libraries in the .NET base class library are unavailable on Mono (like WPF) or porting them hasn’t been finished yet (like Kerberos). You may have to consider alternative approaches in case the functionality is unavailable.

Likewise, even if your application doesn’t rely on unavailable libraries, then it could still make incorrect assumptions about the platform. For example, the way that paths are arranged, and numbers are stored are different from Windows systems. .NET includes built-in functionality to mitigate many of these problems, so you can avoid hard-coding them.

Process and Challenges in Porting Mono The IBM i port of Mono uses the PASE environment instead of the ILE to provide an easier porting experience, being able to reuse most of the existing code for Power Systems. As a side effect of this, an AIX port was created as a by-product of porting to IBM i. Although I had a minimal viable prototype working after about two weeks, it had just barely started working then. It took a lot of effort to fix issues that impacted IBM i, due to the significant differences that it has versus other platforms, combined with the more specialized knowledge required. Unfortunately, it’s less likely you’ll be able to rely on Google and Stack Overflow when porting software with PASE, so I had to talk to many domain experts when I got stuck.

It might help to know how portable the application you’re trying to port is, and if it supports PowerPC or AIX. If so, this makes the porting job much less worrisome since much of the hard work would be completed. In this case, Mono supported Linux on PowerPC in addition to a multitude of other platforms, so I could worry less about critical pieces assuming Intel processors, for example.

To start porting an application, you’ll need its source code to build from. I would personally recommend downloading it from a version control system like Git, as it would be more practical to develop from their latest development version, and a version control can make the processes of integration and triage easier.

Once you have the source code the next step is to build it. You’ll first need all the packages required to build the application. Usually, it will say what it needs in its documentation. If you’re lucky, you might not even need to change everything, and everything will work just out of the box. Unfortunately, due to the complexity and platform-specific requirements of Mono, modifications were required.

While a lot of the details when modifying code are specific to that program, the general process and techniques of doing so are the same. My process to get the minimal viable build is iterative: I build the program, see what issue manifests, research it (in the context of the platform and application), fix it and try building again. When you’re doing the initial porting work, it’s OK to experiment with things you might not be sure about or use ugly solutions; those can be polished up and be done correctly when you finish your work later.

What changes need to be made involve working around features PASE does not have, features it doesn’t fully implement, and bugs. These implementation differences inherited from AIX, which can be quite quirky, or features that haven’t been implemented yet on IBM i. Luckily, developers often foresee these kinds of problems and have workarounds in their code, or at least an easy way to add more workarounds. 

In many C language projects, the build system contains a configure script, which analyzes the system and what features it supports to set up the development environment. More checks and platform-specific preparations can be embedded there. In the source code, either runtime checks can be added, or compile-time conditionals can be used, which makes the compilation of sections optional. In C, this is the #ifdeffeature, which works similarly to ILE RPG’s /if defined()feature.

The problems that come most often in PASE are dealing with the APIs that the POSIX specification (which specifies how UNIX APIs work) provides, or in many cases, doesn’t provide. Unfortunately, POSIX, much like the C language standard, is ambiguous in many cases and omits some expected features entirely. This means a lot of APIs may be implemented in a different way than applications assume they work on Linux, or missing entirely, due to the variations allowed. There are other pain points like how the GNU C compiler and runtime linker work on PASE, that may affect the porting process.

In the process of researching how to solve problems, your questions might not already be answered by others on the internet. You’ll have to do research into system documentation and even C system headers to check for how features are used and possible alternatives. One method you might not have considered is checking how other open-source projects have solved the problem—their code is freely available to view and easily searchable on code sharing sites like GitHub, and if the license is amenable, you could even take their solution outright. Since we’re porting open source software, we can give back by publishing the changes made and the knowledge gained with it.

Sometimes, the program runs into issues you didn’t foresee. In these cases, debugging is required. Unfortunately, PASE debugging tools are a bit rough. The venerable GNU debugger is unavailable for PASE, so you’ll have to fall back upon the old AIX debugger, which doesn’t have many of the creature comforts and compatibility afforded by modern debuggers. You may have to fall back to printing to the console log more often that you’d wish.

Once you have the application working, you should publish your work, and ideally get the upstream project to accept your changes. This is done by submitting your changes to the project, requesting that they be merged in, and they can begin the iterative process of code review to discuss and collaborate over the changes. Using source control, this process is simplified, as your changes can be broken into individual units and easily shared. Once the project decides to merge your code into theirs, you’re basically set! You can make more changes or move onto methods to improve the distribution and development cycle like continuous integration or packaging.


Mono on IBM i introduces new opportunities to use familiar code and development environments in new ways, from using tools like Visual Studio to target the i or adapt existing codebases to run on the same system. While it’s still early in development, it shows a lot of promise and community interest. Hopefully, the open-source community around the platform grows and can keep improving Mono and other future endeavors! 


Stay on top of all things tech!
View upcoming & on-demand webinars →