Mono 2.12 Roadmap

Posted by Jonathan Allen on Oct 20, 2011

Sections

Development

Topics

.NET Framework 4.5 ,

C# ,

.NET Languages ,

.NET Framework ,

Mono ,

.NET ,

Programming ,

WinRT

Share |

RELATED Research

In anticipation of the upcoming Mono 2.12 public beta, Miguel de Icaza has released the planned feature set including many of the .NET 4.5 APIs and C# 5’s Async support. There is also an improved garbage collector, support for the full table of Unicode surrogate characters, and a new backend for the C# compiler.

Before digging into the specific features, a note about versioning: as with previous versions the experimental code starts as version 2.11 and will becomes 2.12 once the Mono team feels that it is stable.

C#

Mono’s C# compiler now has a full implementation of the async/await keywords.

In the past Mono had several C# compilers, each targeting a different profile. With the transition to IKVM.Reflection for the back end, Mono can now offer a single compiler for CLR 2, CLR 4, Silverlight, MonoTouch, and Mono for Android.

TypedReference, and the C# keywords __makeref, __reftype, and __refvalue, are now supported. Just as with Microsoft, the Mono team did not explain the true purpose of this feature.

The C# interactive shell and “compiler as a service” features continue to be improved. The Evaluator.Eval function can now handle entire classes and structs where before only statements and expressions were allowed.

Code Analysis

With Microsoft’s implementation of Code Contracts continuing to linger in MSR, the announcement of a static Code Contract analyzer by Alexander Chebaturkin is welcomed news.

.NET 4.5

The .NET 4.5 profile, disabled by default, includes the new TPL Dataflow libraries. These are expected to offer significant performance advantages to backend developers willing to abide by message passing style design patterns.

The Mono team also intends to implement the WinRT functionality that is applicable to cross-platform development. These include the threading, cryptography, and networking APIs. Miguel de Icaza has explicitly stated that they do not intend to support the GUI libraries from WinRT, as they prefer platform-specific user interfaces.

Garbage Collection

Work continues on the SGen garbage collector. Previously this garbage collectors only marked objects in parallel, the actual collection of the nursery was done on a single thread. The new version will allow for parallel collection as well.

Miguel also mentioned “MacOS/iOS native support” for the garbage collector. We will run a follow-up report when we learn what this actually entails.

1. Back to top

   Not supporting the WinRT GUI libs is a missed oportunity.

   by Marcel Sorger

   Being able to port a WinRT app to Android/IOS quickly can be usefull for apps that have an unique look.
   As all the WinRT stuff will be looking like all the other touch interfaces I doubt there will be huge tweaks needed for a port.
   Touch is all about big buttons and how many way's are there to do those?

   Reply

2. Back to top

   Re: Not supporting the WinRT GUI libs is a missed oportunity.

   by Jonathan Allen

   While I would love to see a XAML stack on Android and iOS, I don't think Mono has the manpower to pull it off at this time.

   Reply