Release Notes Mono 2.6.1
Mono 2.6.1 is a portable and open source implementation of the .NET framework for Unix, Windows, MacOS and other operating systems.
Mono 2.6.1 is a bug fix release for Mono 2.6.
These are some of the major features in this release:
- WCF client and server, the subset exposed by Silverlight 2.0
- LLVM support, to improve performance on server/computational loads
- Co-routine framework Mono.Tasklets
- Preview of LINQ to SQL using DbLinq
- New Soft Debugger, integrated with MonoDevelop 2.2
- Joint release with MonoDevelop 2.2
- csharp shell now supports auto-completion
- xbuild can now build most msbuild projects
- Support for CoreCLR security:
- Mono debuts a full metadata and IL verifier
- Security system used by Silverlight applications, reusable for other cases.
These new features are described below in detail.
Changes since Mono 2.6
Specific bug fixes include:
- r148593 - Fixes the IPY+Chiron test case.
- 556884 - Shadow copies of assemblies cannot be overwritten if originating assembly files are read only
- 545417 - ListView + DataPager fails while trying to set up custom paging
- 565117 - Crash in System.MonoCustomAttrs.IsDefinedInternal
- 565127 - GetGenericParameterConstraints fails on methods in dynamic modules
- 564379 - [REGRESSION] 2.6/git gmcs throws CS1501 on overload/explicit implementation resolution
- 565602 - string.PadRight(int, char) returns empty string
Changes since Mono 2.4
This documents the changes since Mono 2.4.
LINQ to SQL
LINQ to SQL (in System.Data.Linq.dll) is now partially supported through the collaboration of the DbLinq team and the Mono teams. It is known to work for applications like NerdDinner, but it is not fully finished yet.
Mono’s LINQ to SQL is not limited to SQL server. While exposing the same API in System.Data.Linq.dll it is possible to use many other database providers by specifying the database provider on the connection string, the databases currently supported include:
However, the only providers regularly tested are the SQLite and SQL Server providers.
The default provider is Microsoft SQL Server; to specify an alternate provider provide the DbLinqProvider and DbLinqConnectionType parameters. DbLinqProvider specifies which “SQL dialect” to use, and DbLinqConnectionType is the fully qualified .NET type to use for the connection type (permitting late binding). For example, to load a SQLite file using System.Data.Linq.DataContext:
var db = new DataContext("DbLinqProvider=Sqlite; " + "DbLinqConnectionType=Mono.Data.Sqlite.SqliteConnection, Mono.Data.Sqlite, " + "Version=188.8.131.52, Culture=neutral, PublicKeyToken=0738eb9f132ed756; " + "Data Source=Northwind.db3");
DbLinqConnectionType can be skipped if you provide your own IDbConnection instance, e.g.
var conn = new SqliteConnection ( "DbLinqProvider=Sqlite;" + "Data Source=Northwind.db3" ); var db = new DataContext (conn);
System.Data.Linq support is not complete. (At minimum, missing is improved support for databases, CompiledQuery support, support for some method calls within select expressions, and general Linq-to-SQL compatibility.) We would appreciate any feedback and/or bug requests at DbLinq’s bugzilla.
Mono 2.6.1 features a new debugger engine, the Mono Soft Debugger.
This new debugger engine lives inside the Mono process and as opposed to hard debuggers it is more reliable at debugging, but does not allow developers to debug assembly-language when debugging their Mono applications.
This debugger can be used from MonoDevelop and can debug ASP.NET, Moonlight, Desktop, server and iPhone/MonoTouch applications.
Early 4.0 APIs
This release includes partial support for C# 4.0 and includes some of the upcoming .NET 4.0 APIs. Since these APIs have not officially been completed by Microsoft, they could change without notice.
If you want to try out C# 4.0 and the new .NET 4.0 APIs, you should configure Mono with: –with-profile4=yes.
This release includes some components of the ParallelFx framework that were developed as part of Google Summer Of Code 2008 & 2009. More precisely, it contains the Task Parallel Library and Data Structures For Coordination.
Using ParallelFx, you can easily develop software that can automatically take advantage of the parallel potential of today multicore machines. For that purpose, several new constructs like futures, parallel loops or concurrent collections are now available.
To use this code you have to manually enable the .NET 4 profile using the –with-profile4=yes switch at configure stage.
Dynamic Language Runtime
The dynamic language runtime (DLR) is now distributed as part .NET 4 profile. This includes a new System.Dynamic assembly and significantly expanded expression trees in System.Core.
The WindowsBase assembly which was previously part of the Olive module is now part of the standard Mono distribution. This assembly sole purpose is to provide the System.IO.Packaging API, a .NET API for ZIP files that has recently become popular.
176 bugs were fixed. Highlights:
- DataGridView - major stability, functionality and performance improvements.
- PropertyGrid - instability in MDI forms is fixed.
- MaskedTextBox - improved masks handling.
- Linux Clipboard - support added for custom data formats and IDataObject.
- Others fixes: DataGrid, TabControl, TextBox, RichTextBox, WebBrowser, TreeView, ListView and more.
csharp command now supports auto-completion using the tab key.
If Mono 2.6.1 is configured with the preview mode, you will also get early access to Mono’s C# 4.0 implementation. This implementation is now available as part of the dmcs command.
C# 4.0 named arguments and optional parameters have been fully implemented.
xbuild, the Mono implementation of the
msbuild build tool has advanced significantly. It now has support for ASP.NET projects, both WebApplication and WebSite projects.
It can now resolve references from pkg-config files, (for example gtk-sharp.pc)
To allow extending the build system, Before/After* hooks and *DependsOn properties have been added to various targets like Build/CoreCompile/Clean.
build now executes the Pre/PostBuildEvents in the project files.
Important bug fixes to the core, for property/item/metadata evaluation, which improves support for custom msbuild files.
The project file generated from a solution file (.sln), is written to disk only if the environment variable XBUILD_EMIT_SOLUTION is set.
- Added Clean target
- xbuild implicitly picks a .sln or *proj file from current directory, if nothing is specified on the command line
Lots of other bug fixes, besides these from bugzilla:
- 484771 OutDir property is ignored
- 530210 xbuild fails if an unmanaged library is located in a project reference path
- 530368 xbuild enters infinite loop if a build target is named “Build”
- 531276 Documentation missing
- 531926 BeforeBuild/AfterBuild Targets missing
- 532264 xbuild does not support .sln files as MSBuild Project targets
- 533903 When building a .csproj directly, any ProjectReferences are not found
- 534965 xbuild seems to execute tasks repeatedly when the tasks are dependencies of other tasks
- 534992 xbuild is missing _CopyAppConfigFile targets
- 542459 Rebuild target is not implemented
As part of our work on Moonlight, Mono now includes a sandbox and its verifier. There are various pieces to the puzzle:
- IL verifier: to ensure that code fed to the JIT engine is valid.
- Metadata verifier: to ensure that the assemblies processed are valid files and that the JIT will not crash when accessing it, or that the data is invalid.
Verifier integration with the [[Moonlight2CoreCLR CoreCLR Security Sandbox]: the IL verifier can be integrated by those embedding Mono with the CoreCLR security system to prevent untrusted code from using dangerous operations (like pointer access) or access to restricted APIs (for example, file access).
Embedding users can control whether to turn the above on or off.
As part of the gsoc 2009, Jerry Maine ported Mono.Simd to AMD64. It supports mixing code with floating-point and use all available SSE registers.
Minor enhancements to the API were made, some missing operations were added and the documentation fixed to reflect the new extension-method style.
mono_metadata_interfaces_from_typedef now returns the interface array in g_malloc’d memory. It previously allocated it with mempool memory which could only be freed when the image was unloaded.
This is a new and experimental feature in Mono. It is now possible to compile Mono to use the LLVM code generation engine as an optimizing compiler for Mono.
When enabled, LLVM will be used for most code instead of Mono’s Just in Time compiler (there are a few pieces that are not yet supported by LLVM and in those cases Mono will fallback to its internal engine).
Keep in mind that using LLVM has an impact on JIT performance, so this is not recommended for desktop scenarios where startup speed is important. LLVM should be used only for long-running applications or applications where long-term computational speed is more important than startup speed.
The SciMark score on Mono goes from 482 to 610.
The llvm backend requires llvm 2.6.1 or later and can be enabled by passing –enable-llvm=yes to configure.
Support for generics is greatly improved compared to 2.4.
When embedding the Mono runtime, Mono will now allow signal handlers that were set before the Mono runtime was initialized to be invoked when the signal is triggered from non-managed code:
The following signals are chained:
- a SIGSEGV/SIGABRT signal received while executing native (i.e. not JITted) code.
To enable this functionality, embedders must call the mono_set_signal_chaining(gboolean chain_signals) method.
This closes the #318894 feature request. The patch was contributed by Simon Rowland at Linden Labs.
mkbundle can now pass runtime options to the generated executable by setting the
MONO_BUNDLED_OPTIONS environment variable.
Debugging support for GDB
The runtime can now generate debugging information for managed code and register it with gdb when using the –debug=gdb command line option. This only works on some platforms, currently amd64/x86/arm linux, and requires gdb 7.0, which has a JIT interface.
There is a mono support mode implemented in python which offers additional features, like pretty-printing C# objects. It is in the file mono-gdb.py which is installed alongside the mono executable, so gdb will load it automatically.
The Mono.Tasklets library (described in the blog entry Continuations in Mono: Embracing and Extending .NET) is a continuation library that can be used to construct various forms of continuation systems and light weight threads.
A simple way of picturing this is the Mono-version of C’s longjmp/setjmp.
The mdoc(5) format has been extended to support embedding arbitrary XML nodes via a format element. This can be used to embed e.g. HTML that isn’t otherwise supported by the mdoc(5). It’s based loosely in concept on Perl’s =begin blocks. For example:
<format type="text/html"> <a href="http://www.example.com">Arbitrary URL</a>. </format>
The mdoc update and mdoc export-html commands have been updated to honor file timestamps; specifically, if the contents of a file hasn’t changed then mdoc update won’t change the timestamp, and mdoc export-html won’t regenerate an HTML file if the output file is newer than the source file.
mdoc updates –exceptions option now has a added value so that <exception/> elements will only be generated for newly added members. This makes updating documentation easier (as mdoc update won’t re-insert <exception/> elements that you deliberately removed).
mdoc export-html now supports a –with-version parameter so that only types & members within a given version will be documented. This makes it possible to get documentation for a subset of types, instead of needing to manually read each type/member to see if it’s in the version you care about.
mdoc –version now uses Mono’s version.
mdoc export-html now behaves properly when multiple directories are provided as source parameters (e.g. mdoc export-html -o html source1 source2 source3), properly showing the union of all types within html/index.html.
A new mdoc export-html-webdoc tool has been added which “pre-renders” XML documentation into partial HTML content for subsequent use by the webdoc ASP.NET front-end. This can greatly reduce CPU load when displaying documentation.
Installing Mono 2.6.1
Binary Packages and Source Code Downloads:
Source code and pre-compiled packages for Linux, Solaris, MacOS X and Windows is available from our web site from the Downloads section.
Quick source code installation:
If we have no packages for your platform, installing from source code is very simple.
Compile libgdiplus to support System.Drawing:
$ tar xzf libgdiplus-2.6.tar.gz $ cd libgdiplus-2.6 $ ./configure $ make $ make install
Then compile Mono itself:
$ tar xzf mono-2.6.1.tar.gz $ cd mono-2.6.1 $ ./configure $ make $ make install