Over the past few weeks I’ve been playing with cross platform development tools. With Microsoft’s announcement of the Visual Studio Code preview [LINK], the latest version of Mono (version 4.0, built against the C# 6.0 spec) [LINK] and Microsoft open sourcing their entire Core CLR for .NET [LINK], now is the time to be developing in C# (if not before).
If you can’t tell already, this will end up being a post about programming.
One of the many great things about Microsoft open sourcing the Core CLR is that many years of research and development over at Microsoft has just become available to us developers, for free. We’re talking things like garbage collection [LINK], cryptography [LINK] and a whole host of other features.
Also, since the Core CLR is so ingrained into the Windows kernel (there haven’t been any major “scrap it and rewrite it from the ground up” kernels in Windows since NT first came out) that Microsoft are basically ensuring that any code written using the Core CLR is going to run, without major issues on all versions of Windows to come.
Not just the desktop and tablet ones, but the mobile and gaming platforms too.
It also means that code written for the Core CLR can be ported to non-Windows platforms extremely easily. As long as the C++ that it’s written in will compile for the target system, then it’ll be available for it (and the code for the CLR is really well written).
Mono
So Mono is an open source version of the Core CLR (the project had begun several years before Microsoft open source their Core CLR), amongst other things. It’s been written with cross platform development in mind, which means that there are precompiled binaries for Linux, Mac OS and Windows.
The Mono development team haven’t shied away from using any of the recently open sourced Microsoft code in their version of the C# compiler, too [LINK]. Mostly, they’re using the code as either source material for implementing their own versions of some of the C# features that have been buggy or not fully implemented in the past.
Xamarin
Xamarin are the company who own the intellectual property rights for the Mono project. There’s a long story behind it, but the short version is:
- Mono is developed in mid 2000 as a way of getting the .NET CLR on Linux by Ximian
- Novel bought Ximian in 2003
- Attachmate then bought Novell in 2011
- Attachmate lays off hundreds of layoff at Novell (including Mono staff)
- Xamarin are granted full licence to work on all Mono products
Xamarin then went on to make Mono Develop, which was cross platform IDE for Mono. In early 2013, Xamarin announced Xamarin Studio which is based on Mono Develop, but with many advanced features.
Xamarin Studio is able to read and work with Visual Studio projects and create iOS, Android, OSX and Windows applications. It also has most of the features available for Visual Studio (code completion, advanced debugger, UI designer, etc.)
What’s All This Got To Do With Me?
Well, since I’ve been playing around with Mono and Xamarin Studio, I thought I’d write a little about it. I’ve been using Xamarin Studio on my laptop (mid 2010 Mac Pro) for developing some applications and writing some throwaway code.
Why use the Mac?
Mainly because it’s small, fast to boot up and I can take it with me places.
Seriously, if I’m travelling anywhere (say I have a long journey ahead of me) then I can pull down my latest code and do some work while I’m sat around waiting to get where I’m going. It works too – I get quite a lot done on those long journeys (I used to watch a film or something, but now I’m way more productive).
The code view is very similar to most IDE’s (it feels like it is modelled after Visual Studio).
Some filenames have been censored due to the nature of the code being worked on
The designer uses GTK# (a wrapper for the GTK+ library) version 3 for GTK enabled projects.
Some filenames have been censored due to the nature of the code being worked on
What Do You Think of Xamarin Studio?
It’s really quite nice, and very similar to Eclipse and Visual Studio. I really do feel that users of both of those two IDEs will get on well with Xamarin Studio.
However, and I’m not sure whether this is specifically my laptop or not, I’ve noticed a few crashes on opening Solution files. This tends to happen when I’ve got the GitHub GUI open at the same time as Xamarin Studio, so perhaps there’s a file lock issue?
I’ve noticed a similar issue with the GitHub GUI when I’ve got Xamarin Studio open: opening the GitHub GUI after making edits with Xamarin Studio (but having not closed Xamrin Studio), I’m told that I’ve made no edits to any files in the repository.
Plain Sailing?
Not really. I had a bit of a massive issue with compiling and running some Mono code using Xamarin.
When developing on Windows using .NET and C#, Windows does some smart things when creating an instance of the compiled program for execution. One of these is to figure out which system DLLs need to be loaded for the program to run. On non-Windows environments, using Mono this is slightly broken.
What’s meant to happen is that all of the Windows DLLs are mapped to Mono binaries that are compiled for the target OS (OS X Yosemite, in my case). However, this isn’t done automatically, which leads to a lot of instances of errors like this one:
Unhandled Exception:
System.TypeInitializationException: An exception was thrown by the type initializer for Gtk.Container ---> System.DllNotFoundException: gtksharpglue-2
at (wrapper managed-to-native) Gtk.Container:gtksharp_gtk_container_get_focus_child_offset ()
at Gtk.Container..cctor () [0x00000] in /private/tmp/source-mono-mac-4.0.0-branch/bockbuild-mono-4.0.0-branch/profiles/mono-mac-xamarin/build-root/gtk-sharp-2.12.21/gtk/generated/Container.cs:79
--- End of inner exception stack trace ---
at Gtk.Bin..ctor (IntPtr raw) [0x00000] in /private/tmp/source-mono-mac-4.0.0-branch/bockbuild-mono-4.0.0-branch/profiles/mono-mac-xamarin/build-root/gtk-sharp-2.12.21/gtk/generated/Bin.cs:15
After a LOT of Googling and a LOT of reading about how Mono handles DLL mapping, I found a really good and concise answer on StackOverFlow (one of my favourite websites, ever – seriously, there’s a Stack Exchange for every possible subject):
http://stackoverflow.com/a/15655635
The extremely short version is that there needs to be a shell script in the binaries folder which will call the mono runtime with the compiled program as an argument, but also ensuring that the correct Mono library is loaded into /usr/lib before running it. The shell script needs to be run for the compiled binaries to run correctly.
In case the answer is ever removed, or the link doesn’t work for some reason, here is a copy of the shell script that needs to be written:
[sharp]!/bin/sh
export DYLD_FALLBACK_LIBRARY_PATH="/Library/Frameworks/Mono.framework/Versions/Current/lib:$DYLD_FALLBACK_LIBRARY_PATH:/usr/lib"
exec /Library/Frameworks/Mono.framework/Versions/Current/bin/mono ./binaryNameHere.exe
Swapping out [sharp] for an # and binaryNameHere for the name of the binary to run, obviously.
Platypus can also be used to wrap all of that up into a native .app file, too. So that’s cool.
Anything Else?
You’re quite right, I’ve rambled on for long enough as it is.
Oh, one last thing before I go: I’ve been thinking about getting one of the CODE keyboards [LINK], because I keep hearing great things about mechanical keyboards. Although I have used them in the past (all of my early computer experiences include mechanical keyboards), I’ve not had the chance to try one properly as an adult.
Anyway, I’ll leave it at that I think. We’re getting close to 1300 words, which won’t be fun for you to read I guess.
Until next time, have fun!
