Exago Logo
Generic filters
Exact matches only
Exago Logo

Modifying Mono

by | Employee Stories

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.

A few months ago, however, I spent a good deal of time grappling with an issue related to Exago BI’s new JavaScript API; specifically, the JavaScript API running in a CORS environment. The problem was a bit challenging to identify but turned out to be an issue with the web browser silently dropping cookies in those environments. Identifying the problem took a while, and finding any potential solutions seemed to take even longer. There didn’t seem to be any combination of response headers that would allow the browser to save the cookies. At that point, someone suggested using a feature of ASP.NET which allows the use of cookieless sessions. In other words, the session information normally stored and sent to the server in a cookie, could be incorporated into the URL itself. At first glance, this seemed simple enough to address. There is a way, afterall, to simply tell ASP.NET to use cookieless sessions instead of the normal method of storing them in cookies. Making the switch was as easy as changing a single flag in a configuration file, and voila!

Well… almost. As it turns out, a few additional code changes were needed in Exago, and in the JavaScript API specifically, to deal with the change; some security related, but they were mostly minor. After making those changes, I had a fully functional cookieless sessions implementation! In Windows…

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.

BI Newsletter

Stay up-to-date on all things SaaS and analytics with fresh content each month.

Share This