As a senior developer at Exago, my work usually consists of developing innovative enhancements, collaborating with various team members, addressing issues in the product, and assisting on support calls, in addition to a number of other tasks that seem to compound daily. One of the larger enhancements that I was instrumental in, was adding Linux support via the use of the Mono runtime.
Mono is an open-source VM similar to Java’s JVM, but is designed specifically to work with .NET source. It was originally developed by a group at Novell before the company split up, and the original team responsible was allowed to take the project with them. This company was later called Xamarin, and the Mono runtime itself was open-sourced to allow the larger community to fill in the holes where functionality was broken or missing. This also helped the project stay current with the later iterations of the already-open .NET standard.
Last year, Microsoft started open-sourcing some of the official .NET runtime libraries, and as a result, some of the less stable parts of Mono were suddenly working much more efficiently. While we do not ship with Mono, our application works in environments where Mono is installed. To make things easier on our clients, our installer has also been modified to assist in the installation of Mono from the official Mono project repositories. This integration has worked well for a number of years with only minor issues popping up here and there, which were easily resolved with simple code changes in Exago.
After I was sure everything was working, I installed it on our Linux test box to verify everything was functioning there as well. No dice. In fact, it looked somewhat catastrophic. The first error I saw had a stack trace pointing directly to the Mono runtime support libraries. It wasn’t even making it to Exago, and it was already crashing! This was a bit concerning, so I had to take a step back and think about it for a day or two before resuming.
“Now the Mono project on which we, and many other companies, rely for our Linux environment is more stable.”
For the next week or so, I tried everything I could from using newer versions of Mono and installing different web servers, to modifying the way the web servers interface with Exago. I even tried changing the way Exago routes incoming requests! Ultimately, what I realized at the end of all of this investigation was that the problem was not going to be fixed through any modification of Exago or the interfaces to Exago. The problem was with the Mono runtime itself.
Off to the open-source Mono project!
Fortunately, I had already signed up to this project from previous work I had done to address an unrelated issue accessing Oracle databases, so I was somewhat familiar with the process of building the runtime from source. I cloned the repository and checked out the relevant branch where I would begin my investigation.
After much digging, I discovered the source of the problem and was able to put a patch in place. The fix is a bit technical so I won’t bore you with the details, but soon we had a fully functional cookieless sessions environment in Linux! One instance, anyway. This was only on my machine, so there was still a bit of work to allow Exago to use it on new installs.
Since we do not ship with the Mono runtime, fixing the source for it on my machine was only part of the solution. To make it official, and to benefit anyone else attempting to use cookieless sessions with Mono, I opened a bug post against the Mono project, committed my fix, and opened a pull request in order to get the changes incorporated into the main Mono source tree. After a couple of days, my fix was accepted, and now the Mono project on which we, and many other companies, rely for our Linux environment is more stable as a result.