C# and mono: getting some feet wet…
Well, some of the readers of these pages will have noticed that, carefully speaking, my enthusiasm for Microsoft technology is pretty limited. “Limited” indeed is the right way of putting it: While I have a clear opinion about most of Microsofts monopoly regarding desktop and office software (which, in the end, makes me avoid both as good as I can, and thanks at the very least to Ubuntu GNU/Linux, right now I can do that pretty well… 😉 ), I then and now always considered Microsoft .NET, as a development and runtime platform, a pretty good thing, maybe the best technology the Redmond folks came up with to date, and definitely a technology that could have offer wholly new options to both Microsoft and the rest of the world if licensed and distributed a little more openly. Anyway, leaving licensing and personal considerations related to this aspect aside: These days I earn a living mainly off working with Java and overally am pleased with this as an environment. However, as “integration” is what I mostly deal with, I finally had the chance of dealing with Microsoft .NET and C#, and had a rather pleasant trip…
Getting the tools ready
Given the fact that I’m on Ubuntu 10.04 beta on my everyday working notebook, though, running “Microsoft” .NET was not an option. Fortunately, there’s Mono, an open source / software libre project aiming to provide a compatible, portable implementation of .NET for platforms not supported by Microsoft (which is any platform other than Windows, actually). In my Ubuntu installation, as well as in most other GNU/Linux distributions out there these days, one is just a few moments of package manager interaction away from having Mono installed; I personally did so in a rather rude way – by installing MonoDevelop, an open-source IDE for Mono / C#, which subsequently pulls in most of the relevant core mono packages as dependencies. A few dozens of megabytes of package downloading later, things are there, set up and ready to go. So far, so good.
Solving a real-world problem, part 1: integration client
In order to, in our environment, make a legacy (and highly proprietary) document management platform behave well and communicate bidirectionally with other applications / platforms around, we ended up hand-crafting a small “middleware” structure to get this job done. Well, “middleware” is quite an exaggeration for something which basically is HTTP-POST along with a data transfer encoding resembling a lite, stripped-down version of JSON. It’s a pretty bare-bone and rather archaic kind of approach, but then again, it works, it is easy to handle even in this very DMS platform (written in an obscure language in which a more-or-less working TCP socket implementation is the best you probably can get for such a task), and it is a way to easily link many different platforms without having to worry too much about whether or not this approach is supported in the target platform (actually, even unix-shell and netcat eventually would do here… 🙂 ). So doing a few proof-of-concept implementations on top of various languages / frameworks is a good excuse to try the same using C# / .NET. First things first, the easier thing: Building a client posting some data structure via HTTP and dumping the response recieved to STDOUT… Firing up MonoDevelop, if one is used to a Java IDE it takes some time getting acquainted to things, but then again, world’s not all too different here. Creating an initial runnable class is simple, core syntax just slightly different to what one’s used in Java.
So now how to deal with the client side of HTTP? Fortunately, there’s documentation at hand: Along with Mono, there comes “monodoc” which allows for easily browsing pre-installed Mono documentation, mainly of course API reference. monodoc offers a rather good search facility so figuring out that System.Net.WebRequest is what I need. Adding to that, there’s a vast load of documentation available as part of the Microsoft Developers Network (MSDN) library, which, in this special case, offers an almost fool-proof step-by-step guide on how to resolve exactly the kind of problem I need. So overally, getting the C# client to talk to both the DMS and the Java server side of our integration structure took about ten minutes, including figuring out how to, in C#, convert a String object into a byte array. Not bad, and pretty intuitive given the documentation and a good deal of Java experience at hand.
Solving a real-world problem, part 2: integration server
So far, so good – running the client code from within MonoDevelop, or even from the command line, wasn’t a job too tough (even though it feels strange running a .exe file in a GNU/Linux environment… 🙂 ). Now, however, for the server part of things. Given quite a range of servlet containers or application servers (we use Glassfish and apache tomcat for our internal purposes) at hand, a Java developer has quite a concise kind of environment in which to expose HTTP(-POST) services: Extend javax.servlet.http.HttpServlet, override the doPost method, add your code, package a .war file, deploy things to your application server – done. The good thing about Java EE, in my opinion, is that this general workflow does always apply, no matter which application server, development environment, … you are running. But how to do that in Mono/.NET?
So far, I haven’t come across the idea of something like a “generic .NET application server”, akin to what an application server in Java EE is. However, I quickly found out about ASP.NET and mono-xsp(2) server, which I installed using my package management. Fine. Reading the tutorial was rather straightforward, now for some code.
To cut things short: It turned out to be not much more complicated than building the client. Browsing the Mono documentation, and from there the MSDN articles, I quickly came across System.Web.IHttpHandler, implemented it, filled its ProcessRequest method with meaningful code (using code completion in MonoDevelop prove to be a rather good way of exploring the – at least to me – unfamiliar C#/.NET API), running stuff with xsp. Done.
Conclusions…
What to learn from this little trip?
- Well, first off, working with C#, Mono and MonoDevelop is not that much of a pain if you’re used to Java and, given at least this very use case, know what you’re about to want to do. There are tons of documentation available out there, and overally, I guess in most situations getting started with these things should be straightforward.
- As always, learning something new is a good thing, and in case of C#/.NET, I see a strong advantage in linking our existing server-sided environment with desktop-based clients – so far, Java unfortunately doesn’t do that good in terms of deep desktop integration (registering global desktop hotkeys, opening standard applications, …). Throwing in a little bit of local .NET code could ease this at the very least for Windows clients.
- I still have to see how to build a portable, self-containing application server using Mono/C#: Given the nature of .war deployment and the way application servers and JREs can be deployed, it is possible to simply make .zip file of JDK, preconfigured application server along with the applications deployed to it, unzip this file on a server machine, start the application server and have things running as desired – without the need to install additional software, configure system-wide services (apache and mod_mono?) and the like. Comparing this kind of deployment, Java EE still is way ahead of .NET/C#, Python and any other platforms I played with so far.
In the end, that’s what is left: I enjoyed my ride and liked what I saw. I still will be doing most of my work using Java, I still will enjoy working with P/Jython for most scripting things, but I figured out that, in practical use, C#/.NET/Mono is a rather smooth environment to work with, and, as pointed out, there surely are some problems I already imagine for using it… More to come.