Monday, June 28, 2004

PROG: Mono beta 2 released

Mono Installation


1. Mono Beta 2 Introduction.
2. Contents of the Beta.
3. Changes since Beta 1
4. Known Issues
5. Logging bugs against Mono
6. Contributors
7. Contact Information

Mono Beta 2

Novell is proud to introduce the second Beta release of Mono, an open source implementation of the .NET framework for use on Linux, UNIX and Windows System.

It includes a C# compiler, an implementation of the Common Language Infrastructure and two stacks of APIs: a UNIX, Linux, GNOME, Mono stack for APIs that takes the most advantage of your UNIX server and desktop and a set of APIs compatible with the Microsoft .NET Framework 1.1 that provides support for ASP.NET (web services and web forms), ADO.NET and many other components.

Incorporating key .NET compliant components: a C# compiler, and a portable execution system (that includes Just-in-Time and pre-compilation support), the Mono Project:

* Provides a superior development environment for writing Linux applications with unprecedented productivity.
* Allows developers to write rich client, web services and server-side applications and deploy them on Linux, Solaris, MacOS X, Windows NT/XP and various other UNIX systems on a variety of architectures.
* Delivers tools that facilitate the creation of product APIs and SDKs that are language independent across multiple operating systems.

Current Users

Mono, in addition to running many of the existing .NET software (or popular software adapted to it like Nant, Nunit and Ngallery) also is used elsewhere.

It is being used internally at Novell to develop:

* iFolder 3.0: a file system that provides synchronization, peer-to-peer sharing and metadata handling.
* Beagle/Dashboard: search tools for the desktop.
* F-Spot: a photography management application.
* Extensibility for the Nautilus file manager and hooks into iFolder.

Outside of Novell, Mono is being adopted by vendors such as:

* SourceGear which relies on it to run its Vault application on Linux,
* the ASP.NET engine for OpenLink's Virtuoso database,
* Voelcker Informatik uses it to provide services to the City of Munich, and
* Mainsoft uses it as the foundation for the Visual Mainsoft for J2EE product.

It is also being used by the community for various projects:

* MonoDevelop an IDE based on SharpDevelop adapted to Linux.
* The Nemerle functional language, and
* The Gnome Fax program.

Beta 2 Release Goals

This release is the second and last Mono 1.0 beta releases planned before our final release.

This is an opportunity for developers outside of the contributing community to experience mono on their platform of choice. One of our main objectives is to make it easy for the novice or experienced Linux or Windows developer to start building applications on Linux or other platforms right away.

We paid a lot of attention in this release to installation and package availability for the following platforms: Red Hat 9.0, Fedora Core 1, Novell SUSE 9.0, Novell SUSE SLES 8, MacOS X and Microsoft Windows 2000 and XP.

This Beta is signature compatible with the .NET Framework 1.1. Although we are signature compliant for every assembly we ship, not all the functionality is available, most importantly the following are not supported:

* COM support of any kind in UNIX or Windows.
* EnterpriseServices is only a set of stub routines.
* Windows.Forms is only available as a preview, and it is not meant for production use.
* Code Access Security (CAS) is not supported: missing in the runtime and class libraries.

Just like any Beta release, we welcome any bug reports and suggestions.
Contents of the Beta 2
The Mono Beta 2 includes:

* ECMA CLI-based virtual execution system.
* Java VM: allows Java and .NET code to run side-by-side. It contains the latest release of IKVM.
* Optimizing compiler for x86, PowerPC, SPARC and S390 based architectures.
* Just-in-Time (JIT) and Ahead-of-Time (AOT) compilation modes supported.
* A new, faster interpreter for the above platforms and also for StrongARM and HPPA.
* Support for Linux, MacOS X, Windows, Solaris and HP-UX operating systems.
* C# 1.0 compiler.
* Development toolchain.
* API documentation browser, with Wiki-like capabilities.
* Embeddable runtime: make your application scriptable and extensible with C# or any other .NET language using our embedding API.

Mono Stack

Microsoft .NET Compatible Stack

* Gtk# for GUI development.
* Database providers for: Postgres, MySQL, DB2, Sybase, Sqlite, Oracle.
* LDAP libraries (Novell.LDAP).
* Complete cryptographic stack.
* Apache module integration.
* Cairo graphics integration.

* ASP.NET Web Services.
* ASP.NET Web Forms.
* Binary and SOAP remoting.
* ADO.NET: connectivity to SQL Server and other databases.
* System.Drawing API.

In addition, we are also previewing a few features from the Mono 1.2 release, none of these are supported at this time:

* Preview C# 2.0 compiler with generics support (gmcs).
* Generics-enabled virtual machine.
* System.Windows.Forms.
* Mono Basic compiler.

Gtk# is part of this release as well: a set of .NET bindings for the Gtk+ toolkit. This library allows you to build fully native Gnome application using Mono and includes support for user interfaces built with the Glade interface builder.

User testimonials indicate that Gtk# provides developers with great productivity for building graphical applications especially when compared to GTK+ or Java Swing : "Gtk# and Mono have proven to be an outstanding combination for delivering rich client applications to the Linux desktop...Gtk# and Mono's tight integration with the GNOME/Ximian desktop enables us to deliver desktop plugins written entirely in managed code. Today, this level of integration is not possible on Windows with .NET and Windows Forms." says Brady Anderson from the iFolder project.

Applications built using Gtk# will run on many platforms including Linux, Microsoft Windows (with our Microsoft Windows GTK+/Gtk# runtime support) and Apple MacOS X. While our System.Windows.Forms implementation is making good progress and will allow user to run graphical .NET SWF based application on Linux, Gtk# is the Mono project main graphical toolkit for cross platform application development and tight Linux integration.

In late 2003, a few developers from the Mono community began migrating SharpDevelop, a successful .NET open Source IDE from SWF on Windows to Gtk# to Linux. We are pleased to release the result of their efforts, MonoDevelop with Mono 1.0 Beta 2 and the final release of Mono 1.0.

In a short amount of time, MonoDevelop has become a very complete IDE for Mono including features such as syntax highlighting, code completion, import of Microsoft Visual Studio .NET solutions and it integrates the MonoDoc system.
Installing Mono Beta

Binary Packages:

Pre-compiled packages for SUSE 9, SUSE 9.1, Red Hat 9, SLES 8, Fedora Core 1, Fedora Core 2 and MacOS X are available from our web site from the download section. A Red Carpet Mono channel is also available on these platforms.

Source code:

* Mono runtime
* MCS (Mono C# compiler)
* libgdiplus
* LibWine
* Gtk#
* Monodoc
* XSP ASP.NET host
* Apache module integration


If you are installing from source code, there are a few optional dependencies that you will want to consider installing.

icu 2.6.1 or later Optional: for supporting string collation.

Cairo 0.1.23 Required to install libgdiplus.

Quick source code installation:

If we have no packages for your platform, installing from source code is very simple.


$ tar xzf mono-0.95.tar.gz
$ cd mono-0.95
$ ./configure
$ make install

Optional Packages

Libgdiplus and WineLib are optional packages, you only need those if you intent to use System.Drawing and Windows.Forms respectively.


$ tar xzf libgdiplus-0.8.tar.gz
$ cd libgdiplus-0.8
$ /configure
$ make install

For WineLib, it is necessary first to install a Wine package from Wine HQ, and once that is installed, you can install the WineLib package, which is now just an extension to Wine instead of a modification to Wine:

$ tar xzf winelib-0.3.tar.gz
$ cd winelib-0.3
$ ./configure
$ make install

Changes since the Beta1 release.
The following is a list of changes since the Mono 0.91 release:
C# Compiler Bug Fixing.

Ben Maurer, Marek Safar, Martin Baulig, Miguel de Icaza Raja Harinath contributed plenty of bug fixes to Mono's C# compiler for this release: Obsolete attributes are better supported, better error checking, all critical and blocker bugs have been fixed at this point.

MCS went on a diet as well, and Ben shrunk 7 megabytes of memory usage in a typical bootstrap.
pkg-config integration

The Mono C# compiler now integrates with pkg-config: it is possible for library developers to ship a pkg-config description file for their libraries.

For instance, to compile gtk-sharp and gtk-html software, now you can use: $ mcs -pkg:gtk-sharp sample.cs
New Thread.Abort implementation.

Lluis architected and implemented a new implementation for Thread.Abort. This is one of the areas that could make the runtime unstable if a thread was aborted while it held unmanaged resources. Now a new architecture has been put in place that solves this problem.

The Thread.Abort problem would actually surface in many different forms across the board, particularly in ASP.NET, those issues are now gone.

Patrik Torstensson and Lluis Sanchez got our Runtime.Remoting stack to pass all of the regression tests for the first time: a combination of fixes in our runtime, the managed libraries and the Tcp transport were done to fix all of the outstanding problems.
Mono Runtime

The Mono runtime is now statically linked against libmono, which means that it's simpler to debug it, but is also slightly faster.

Plenty of bug fixing occurred in this release in every component of the runtime: io-layer, metadata reading, internal calls, code generation and optimizations.

Zoltan added support for AsAny marshalling.
Code generator improvements

Massimiliano Mantione checked in his implementation of Arrays-Bounds-Check elimination for the Mono VM. If the JIT can infer that an index will remain within range, it can now eliminate the expensive tests for ranges.

Use the -O=abcrem to use. Since this optimization is fairly expensive it is not turned on by default in the JIT, it is recommended that you use this with the Ahead-of-Time compilation flag (--aot).

The old setup that used gcc exception information in internal calls has been deprecated and instead Zoltan has optimized the code paths to use the regular trampoline-based approach. This is not only more reliable, but does not depend on gcc/glibc to be kept in sync.
X86 code generator improvements.

Patrik Torstensson made the register allocator favor physical registers in favor of virtual registers and reduced the spill/load in 30%. He also added various peephole optimizations to use membase addressing compared on X86 and implemented a new allocator for operations on 64-bit values (shl and shr are now inlined as opposed to use helper routines).
SPARC code generator

Zoltan Varga continued updating the SPARC port to keep it in sync with the other ports as well as adding a few new optimizations and checking in the support for Linux/SPARC from Mark Crichton.
S390 support

Neale Ferguson has updated the S390 support to match the rest of the code generators.
PowerPC and MacOS support

Paolo Molaro continued to improve the PowerPC code generation engine and added support for the POWER 4 CPUs. The entire Mono stack is now routinely used on MacOS X, and even large applications like MonoDevelop are running flawlessly on it.

Dick has fixed various problems in our io-layer related to the MacOS X.
I/O libraries

Dick Porter has contributed the File Locking support to File and FileStreams. We use advisory UNIX locks, but notice that Mono will respect the more strong Windows semantics across Mono processes.

Notice that by default files are open with the file share mode set to none, this might break older software that did not take this into account.
Java and IKVM

Mono ships with the new code drop from IKVM with the new renamed commands.

Please visit the IKVM site for more information.

Konstantin Triger and Boris Kirzner from Mainsoft contributed a new implementation of the internal data storage in System.Data.

Data is now stored in typed arrays for improved performance, less objects are allocated.

Container arrays never shrink, but the allocated space is reused between different rows.

Atsushi Enomoto and S Umadevi continued doing bug fixing on this namespace: A large number of changes were done in the DataSet xml handling. It now infers, creates and handles relationships, namespaces, simple content columns and several other elements better than before.

XmlDataDocument has been tuned for performance, and many problems were fixed there.

Atsushi also improved xsd.exe: TypedDataSetGenerator supports more functionality such as DataRelation based features.

xsd.exe now supports a custom ICodeProvider with the -generator option. This enables the user to generate code in any languages that have a CodeDomProvider.
XSP, System.Web and Web.Services

Gonzalo added support for sessions in Web Services and fixed the cookieless sessions and chunked encoding (server size).

XSP now supports virtual hosts thanks to a patch from Jaroslaw Kowalsky. To configure virtual hosts, you can use a file with the extension .webapp, it looks like this:




More details are available on the manual pages.
ByteFX.Data provider

Duncan Mak updated the ByteFX.Data provider for MySQL to the latest publicly available version.
Cryptography and Security

Sebastien Pouliot has started an audit on our core libraries for potential security problems. Strengthening preconditions and avoiding integer overflows as well as auditing our web server and underlying class libraries.

Atsushi Enomoto has contributed a 51932 code page for Japanese encodings as well as fixing various DateTime issues.
JScript and VB.NET

Cesar Lopez continued his work on the JScript engine: switch, using, with, for, exceptions are now implemented.

Anirban and Rafael continues to work on the VB.NET compiler grammar, and Dennis Hayes contributed to the continued effort to port the VB.NET runtime from Java to C#.

Some bugxies are done. Now, with XmlSchema is written using custom serialization code created by Lluis's code generator and became faster than before. XSLT extension function "msxsl:node-set" is implemented.

Atsushi Enomoto contributed some API improvements and major bugfixes on RELAX NG compact syntax are done. That is helped by Jeff Rafter's "anglia" test collection (that was announced on relaxng-user mailing list). Also, there is now documentation available.
Windows Forms, System.Drawing

Jordi, Ravindra and Sanjay continue to work on System.Drawing API. Now images can be rotated, bitmaps can be locked, GIF and TIFF files are supported and there were plenty of bug fixes. Most of the converters are done (only FontConverter is missing).

All Hatch brushes are completed (with its 53 styles)

Peter Bartok has continued his work on Windows.Forms, and many more applications run, most of the basic tests are now operational, and he is working now on a control-per-control basis to complete it. Notice that Windows.Forms is only shipping as an alpha preview with Mono 1.0
Bug fixing, completion

On the runtime engine, Patrik Torstensson has fixed various outstanding complex problems related to app-domain code reuse.

Matthijs ter Woord contributed to the Html32TextWriter class.

Gert contributed many small API changes all throughout the class libraries as well as getting many different attributes correctly in our class libraries. A big help in our push for API signature compatibility.

Mike Kestner did our API completion for EnterpriseServices.
Testing and Packaging

Duncan Mak has setup a continuous build tool with the help of Fawad Halim. Duncan continues to manage the packaging on UNIX, and Gonzalo Paniagua has provided the Windows installer.
Known Issues
Gtk# applications fail to start with `Cannot open font file for font Verdana 12'

This is only an issue if you are executing Gtk+ applications remotely from MacOS X. To solve this, use the following workaround: $ export GDK_USE_XFT=0
Logging Bugs Against Mono

One of our main goals for releasing Beta software is of course to encourage developers to use our software and help us make it a stable, feature complete and reliable system. In order to achieve that goal, we ask you to report bugs as you find them. For this, you will need to create a Bugzilla Account.

Here are some convenient shortcuts to browse or add bug reports.

* [Query] [Add] Class Libraries

* [Query] [Add] IL Assembler.

* [Query] [Add] C# Compiler.

* [Query] [Add] Runtime

* [Query] [Add] Documentation system.

* [Query] [Add] Gtk#

* [Query] [Add] ASP.NET WebForms

* [Query] [Add] ASP.NET Web Services

* [Query] [Add] Debugger.

* [Query] [Add] Mono Develop.

* [Query] All core components.

How to make good bug reports

1. Submit a test case, the smaller, the better.

2. Use http://bugzilla.ximian.com to report the bug.

In addition to bugzilla, posting to the list is fine if the bug merits larger exposure or design discussions to solve; posting to the list twice or more is just a way to annoy people and make them waste time, specially when you start a new thread about it.

3. If the test involves libraries or assemblies that are not part of mono, add information on where to download all dependencies, and how to compile/install them.

4. If compiling the test case requires more than:

mcs test.cs

provide the full command line you used to compile the test.

5. If running the test requires more than:

mono test.exe

provide the full command line needed to replicate the bug.

6. Provide info about the version of the software you're using (both mono and the operating system or relevant libraries).

7. Provide the output you expect the test case to produce.
8. Provide the actual output you get from the test case.

Please include at least 6 items from the list in your bug report. Incomplete bug reports are very hard to understand, reproduce and fix.

Mono would not be possible without the help of a large community of developers and users as well as the contributions of Mainsoft, OpenLink and SourceGear.

Individuals are at the core of the project development process. The developers that contributed since the Mono Beta 1 are:

Alon Gazit, Andreas Nahr, Andrew Arnott, B Anirban, Benjamin Jemlich, Ben Maurer, Bernie Solomon, Boris Kirzner, Carlos Alberto Cortes, Carlos Guzmàn, Cesar Natarèn, Christopher McGinnis, David Sheldon, David Waite, Dennis Hayes, Derek Woo, Dick Porter, Duncan Mak, Elan Feingold, Erik Dasque, Fawad Halim, Francisco Figueiredo Jr., Gert Driesen, Gonzalo Paniagua, Gustav Munkby, Gustavo Giràldez, Iain McCoy, Jackson Harper, Jaroslaw Kowalski, Jean-Marc Andrè, Jeroen Zwartepoorte, John Luke, Jonathan Pryor, Jordi Mas, Jörg Rosenkranz, Joshua Tauberer, Larry Ewing, Lluis Sanchez, Lluis Sanchez, Marek Safar, Mark Crichton, Martin Baulig, Martin Willemoes, Massimiliano Mantione, Miguel de Icaza, Mike Kestner, Mike Shaver, Neale Ferguson, Nick Drochak, Owen Fraser-Green, Paolo Molaro, Patrik Torstensson, Pawel Rozanski, Peter Bartok, Rachel Hestilow, Radek Doulik, Rafael Teixeira, Raja R Harinath, Ravindra Kumar, Robert Shade, Roops, Sachin Kumar, Sanjay Gupta, Sebastien Pouliot, S Umadevi, Todd Berman, Urs Muff, Vladimir Vukicevic and Zoltan Varga.

This list is not complete, but we will update it in the next few weeks, if your name is missing, please let us know.

For any direct feedback (excluding bug reports) regarding Mono 1.0 Beta 2 please contact monobeta@ximian.com.

Other venues are available for discussion about Mono, including our mailing-lists and IRC channel (#mono on irc.gnome.org).


Post a Comment

<< Home

Get Firefox!