New subject: mono packaging, for wine packagers or anyone else who wants to follow along

1 Oct 2010


      Buried in the 1.3.4 announcement is a tiny, insignificant little
change that makes it possible for distributors to package Mono for
Wine:
mscoree: Search for Mono in some predefined paths before using the registry.
As happy as I am to have sneaked this in under the radar, as it were,
I guess I'm going to have to tell someone if it's ever going to be
useful.
I have no plans to make an official Wine Mono distribution. It should
be easy enough for anyone to build.
We currently do not require any changes in Mono for use with Wine.
When we do (and it will be soon), I will try very hard to get the
things we need merged upstream. Any managed libraries we need instead
of or in addition to those shipped with Mono will have to go in Wine.
We don't need a fork yet, and I hope we can keep it that way.
Mono installs are generally self-contained and do not interfere with
each other. Mono does not have to be installed into a bottle before it
can be used. Therefore, I have not programmed any sort of install
process into Wine. It will simply search for Mono as needed.
If you are a distributor, here is how I recommend you distribute Mono
for use with Wine:
Download and extract the mono 2.6.7 source tarball from
http://ftp.novell.com/pub/mono/sources/mono/mono-2.6.7.tar.bz2
Use the instructions at http://wiki.winehq.org/Mono to cross-compile
Mono 2.6.7 using mingw32. Tweak the script if you have to (or just
want to), but consider contributing any fixes you have to make back to
winezeug.
This will create a directory named mono-2.6.7. The contents of that
directory should be installed to /usr/share/mono/mono-1.0.
To make sure this worked, you should try a simple "Hello World" .NET
application in Wine. Wikipedia has an example at
https://secure.wikimedia.org/wikipedia/en/wiki/C_sharp_programming_language#...
that you should be able to save as a .cs file and compile to a .exe
file using gmcs. If all is well, you should be able to run that exe
file in a clean Wine prefix.
In the future, we'll need a mono-2.0 directory as well, so we can keep
using newer versions of Mono and get .NET 4.0 support. But we're not
there yet.
In case all these numbers have not confused you yet, the current
version of Mono is 2.6.7. This version uses the Mono Embedding API
version 1.0, which is why it needs to be placed in a directory named
mono-1.0. It normally includes .NET 1.1 and 2.0 runtimes. It can
optionally be compiled with a 4.0 runtime as well, but I don't
recommend it.
I'm expecting to see Mono 2.8 released "soon". That version will use
the Embedding API version 2.0, which Wine can't support yet, but when
the time comes it will need to be in a directory named mono-2.0. It
will include .NET 2.0 and 4.0 runtimes.
.NET 3.0 and 3.5 are not runtimes, which is why they were not included
in that list. They use the .NET 2.0 runtime.
While Mono 2.8 (and eventually 3.0) is the way forward for .NET 2.0
and 4.0 support, we'll need to also have the 2.6 series available so
that we can have a .NET 1.1 runtime. Wine will detect which versions
are available and what runtimes they have using a system that I'm
working on and hope to have ready "soon", and it will select the
correct runtime for whatever it's trying to run, or whatever the
program selects using the .NET embedding API. (Also coming soon: the
.NET embedding API.)
I'm treating Mono as an optional dependency, much like the many native
libraries Wine already uses. If it's not there, Wine will gracefully
report failure to applications that try to use it, which probably
won't work, and print some things to the console. I plan to send some
changes soon that happen to cause a Wine without Mono to fail some
tests, so I do consider an install that's missing Mono to be broken.
But for the most part, the user experience will remain the same as it
was before if Mono is missing.