Alexander Köplinger releases

Mono 5.0 is out in the stable channel !

Highlights include shipping the Roslyn C# compiler and msbuild, enabling concurrent SGen garbage collection by default and continued integration of code shared with .NET.

Check out our release notes for more details about what is new on Mono 5.0.

This release was made up of over 2000 commits since Mono 4.8 and is the result of many months of work by the Mono team and contributors!

New Linux package repository structure

Linux users: we switched our package repositories to a new structure which means we’re now using a separate repository for each supported Linux distribution instead of one for all. This means you need to update e.g. your apt feed lists, please head over to the download page for updated instructions.

Read this blog post for more background info on the change.


Jo Shields linux, plans

Up to now, Linux packages on mono-project.com have come in two flavours – RPM built for CentOS 7 (and RHEL 7), and .deb built for Debian 7. Universal packages that work on the named distributions, and anything newer.

Except that’s not entirely true.

Firstly, there have been “compatibility repositories” users need to add, to deal with ABI changes in libtiff, libjpeg, and Apache, since Debian 7. Then there’s the packages for ARM64 and PPC64el – neither of those architectures is available in Debian 7, so they’re published in the Debian 7 repo but actually built on Debian 8.

A large reason for this is difficulty in our package publishing pipeline – apt only allows one version-architecture mix in the repository at once, so I can’t have, say, 4.8.0.520-0xamarin1 built on AMD64 on both Debian 7 and Ubuntu 16.04.

We’ve been working hard on a new package build/publish pipeline, which can properly support multiple distributions, based on Jenkins Pipeline. This new packaging system also resolves longstanding issues such as “can’t really build anything except Mono” and “Architecture: All packages still get built on Jo’s laptop, with no public build logs”

Mono repo pipeline

So, here’s the old build matrix:

Distribution Architectures
Debian 7 ARM hard float, ARM soft float, ARM64 (actually Debian 8), AMD64, i386, PPC64el (actually Debian 8)
CentOS 7 AMD64

And here’s the new one:

Distribution Architectures
Debian 7 ARM hard float (v7), ARM soft float, AMD64, i386
Debian 8 ARM hard float (v7), ARM soft float, ARM64, AMD64, i386, PPC64el
Raspbian 8 ARM hard float (v6)
Ubuntu 12.04 (*) ARM hard float (v7), AMD64, i386
Ubuntu 14.04 ARM hard float (v7), ARM64, AMD64, i386, PPC64el
Ubuntu 16.04 ARM hard float (v7), ARM64, AMD64, i386, PPC64el
CentOS 6 AMD64, i386
CentOS 7 AMD64

The compatibility repositories will no longer be needed on recent Ubuntu or Debian – just use the right repository for your system. If your distribution isn’t listed… sorry, but we need to draw a line somewhere on support, and the distributions listed here are based on heavy analysis of our web server logs and bug requests.

You’ll want to change your package manager repositories to reflect your system more accurately, once Mono 5.0 is published (Update: Mono 5.0 is now live, please check out the new instructions on the download page).

We’re debating some kind of automated handling of this, but I’m loathe to touch users’ sources.list without their knowledge. CentOS builds are going to be late – I’ve been doing all my prototyping against the Debian builds, as I have better command of the tooling. Hopefully no worse than a week or two.

(*) this is mainly for Travis CI support which still uses Ubuntu 12.04 for now (despite it being EOL)



Miguel de Icaza runtime

While Mono has had support for SIMD instructions in the form of the Mono.SIMD API, this API was limited to run on x86 platforms.

.NET introduced the System.Numeric.Vectors API which sports a more general design that adapts to the SIMD registers available on different platforms.

The master branch of Mono now treats the various Vector operations as runtime intrinsics, so they are hardware accelerated. They are supported by both the Mono JIT compiler on x86-x64 platforms and via LLVM’s optimizating compiler on x86-64 and every other Mono/LLVM supported platform.

We would love to see you try it and share your experience with us.


Miguel de Icaza plans

Mono’s use of Reference Source Code

Since the first release of the .NET open source code, the Mono project has been integrating the published Reference Source code into Mono.

We have been using the Reference Source code instead of the CoreFX, as Mono implements a larger surface area than what is exposed in there - Mono implements the .NET Desktop API.

Integrating the code sometimes is easy, we replace the code in Mono with the reference source code. When the code is not exactly portable, we need to make it portable and either write missing code, or integrate some of the work that we did in Mono, with the code that existed in .NET. There are some cases where porting the code is just too complicated, and we have not been able to do the work.

We keep track of the major items in Trello.

Originally, we forked the reference source code and kept a branch with our code, but it was too large of an external dependency and it was also a module that was quite static. So recently, we started copying the code that we needed directly into Mono.

While this has worked fine for a while, the .NET Reference Source is only updated when a major .NET release takes place, and it tracks the version of .NET that ships along with Windows. This means that we are missing on many of the great optimizations and improvements that are happening as part of .NET Core.

The optimizations and fine tuning typically take place in two places, work that goes into mscorlib.dll is maintained in the coreclr module while the higher level frameworks are maintained in the corefx module.

A New Approach

Many of the APIs that were originally removed from CoreFX are now being added back, so we can start to consider switching away from referencesource and into CoreFX.

After discussing with the .NET Core team, we came up with a better approach for the long-term maintenance of the shared code.

The .NET team has now setup a new repository where the cleaned up and optimized version of mscorlib.dll will live in the corert module.

What we will do is submodule both CoreRT and CoreFX and replace our manually copied code from the Reference Source with code from CoreRT and CoreFX.

The twist is that for scenarios where Mono’s API surface is larger, we will contribute changes back to CoreRT/CoreFX where we either add support for the larger API surface, or we make the API pluggable (likely with a tasteful use of the partial modifier).

One open issue is that Mono has historically used a single set of framework libraries (like mscorlib.dll, System.dll etc.) that work across Linux, MacOS, Unix and Windows and they dynamically detect how to behave based on the platform. This is useful on scenarios where you want to bootstrap work in one platform by using another one, as the framework libraries are identical.

CoreFX takes a different approach, the libraries are tied to a particular platform flavor.

This means that some of the work that we will have to do will involve either adjusting the CoreFX code to work in the way that Mono works, or give up on our tradition of having the same assemblies work across all platforms.