mono-project.com Linux packages, January 2015 edition

The latest version of Mono has released (actually, it happened a week ago, but it took me a while to get all sorts of exciting new features bug-checked and shipshape).

Stable packages

This release covers Mono 3.12, and MonoDevelop 5.7. These are built for all the same targets as last time, with a few caveats (MonoDevelop does not include F# or ASP.NET MVC 4 support). ARM packages will be added in a few weeks’ time, when I get the new ARM build farm working at Xamarin’s Boston office.

Ahead-of-time support

This probably seems silly since upstream Mono has included it for years, but Mono on Debian has never shipped with AOT’d mscorlib.dll or mcs.exe, for awkward package-management reasons. Mono 3.12 fixes this, and will AOT these assemblies – optimized for your computer – on installation. If you can suggest any other assemblies to add to the list, we now support a simple manifest structure so any assembly can be arbitrarily AOT’d on installation.

Goodbye Mozroots!

I am very pleased to announce that as of this release, Mono users on Linux no longer need to run “mozroots” to get SSL working. A new command, “cert-sync”, has been added to this release, which synchronizes the Mono SSL certificate store against your OS certificate store – and this tool has been integrated into the packaging system for all mono-project.com packages, so it is automatically used. Just make sure the ca-certificates-mono package is installed on Debian/Ubuntu (it’s always bundled on RPM-based) to take advantage! It should be installed on fresh installs by default. If you want to invoke the tool manually (e.g. you installed via make install, not packages) use

cert-sync /path/to/ca-bundle.crt

On Debian systems, that’s

cert-sync /etc/ssl/certs/ca-certificates.crt

and on Red Hat derivatives it’s

cert-sync /etc/pki/tls/certs/ca-bundle.crt

Your distribution might use a different path, if it’s not derived from one of those.

Windows installer back from the dead

Thanks to help from Alex Koeplinger, I’ve brought the Windows installer back from the dead. The last release on the website was for 3.2.3 (it’s actually not this version at all – it’s complicated…), so now the Windows installer has parity with the Linux and OSX versions. The Windows installer (should!) bundles everything the Mac version does – F#, PCL facades, IronWhatever, etc, along with Boehm and SGen builds of the Mono runtime done with Visual Studio 2013.

An EXPERIMENTAL OH MY GOD DON’T USE THIS IN PRODUCTION 64-bit installer is in the works, when I have the time to try and make a 64-build of Gtk#.

3 Responses to “mono-project.com Linux packages, January 2015 edition”

  1. […] GNU/Linux (the winners at Microsoft’s expense). Here we have Microsoft’s proxy Xamarin producing yet another Microsoft entrapment for GNU/Linux users (Mono) and here we have Microsoft trying to repurpose Free software as Microsoft lock-in. When […]

  2. cert-sync /etc/ssl/ca-bundle.pem fails for me on openSUSE and I have no idea how to fix that. This essentially breaks nuget so I have to stay on Mono 3.10 until that is fixed. The previous mozroot command worked and was easy to automatize in the RPM %post script section.

    Also can you also release the tarballs at http://origin-download.mono-project.com/sources/nuget/ you use to build your Xamarin Nuget RPM packages, please?

  3. cert-sync /etc/ssl/ca-bundle.pem fails for me on openSUSE and I have no idea how to fix that. This essentially breaks nuget so I have to stay on Mono 3.10 until that is fixed. The previous mozroot command worked and was easy to automatize in the RPM %post script section.

    Try https://github.com/directhex/xamarin-mono/blob/master/debian/patches/0001-Workaround-for-X509Certificate.RSA-throwing-an-unhan.patch

    Also can you also release the tarballs at http://origin-download.mono-project.com/sources/nuget/ you use to build your Xamarin Nuget RPM packages, please?

    I don’t have my SSH key to fix this directly on this computer, but in general, look in /repo/debian/pool/main/ for anything that seems to be missing – the .orig.tar.* files correspond 1:1 to what *should* be in /sources/. Or grab the SRPM from /repo/centos/SRPMS/ if you prefer (again, it’s the same file)

Leave a Reply