Mono packaging status

Vincent Povirk madewokherd at
Wed Apr 18 17:12:56 CDT 2012

So, I've finally had some time to work on Mono packaging. I think I
have a sort of "first draft" ready.

The goal is to create an MSI package of Mono, similar to the one we
use for Gecko, which Wine will install automatically when updating a
prefix, unless native mscoree is installed. This package will include
all the Mono runtime files, as well as any registry keys and files
that need to be installed to the Windows system for .NET
compatibility. Anything .NET that we want to replace (including XNA,
WPF, and msvcm libraries) will be included. Ideally, with this package
installed, any official installers for .NET components will decide
they are already installed and do nothing. To install native .NET, it
will be necessary to uninstall the Mono package (using "wine
uninstaller --remove '{E45D8920-A758-4088-B6C6-31DBB276992E}'", which
will continue to work for the foreseeable future). Before the Mono
package is installed, and after it is removed, no .NET registry keys
or files will be present, so in theory the installers will just work
(but in practice they probably will require work-arounds for Wine

There will be only one package for 32-bit and 64-bit. Most of the
compiled code is architecture-independent, so it doesn't make much
sense to have separate packages.

The Mono package versions will be loosely tied to Wine version. On
prefix creation time, Wine will attempt to install the version it
"prefers". Due to limitations of MSI, this may mean that Wine will
upgrade Mono automatically but never downgrade it. Because the Mono
API is stable, it should be possible to use any Mono package with any
Wine version back to 1.5.1, which was the first version to search for
the Mono runtime dll based on architecture.

I'm currently publishing the source code at, but I'm not sure if that is
a good permanent home. I do want to keep it on github so I can make
and accept pull requests. I'm using submodules, so it will be
necessary to clone with --recursive and update the submodules from
time to time. The build process requires mingw-w64 (both 32-bit and
64-bit), Wine, and a version of the Mono C sharp compiler (gmcs or
dmcs, I think), and not surprisingly is done by running There should never be any more requirements, and
I'd like to keep the version requirements on those as broad as I can.
I want this to be easy to build, so other people can work on it.

The 64-bit part appears to work on Windows, but it is not useful on
Wine currently. I'll be working on fixing that, or at least getting
Alexandre bug reports and test cases so he can work on it. I think
that when it is fixed, we'll have a lot more 64-bit processes than we
used to, for better or worse.

For now, the only way to install the package is with msiexec.

The current version is based on Mono 2.11.0, which has a serious
deadlock bug on Windows. This will need to be resolved before I can do
an actual release. Otherwise, I'm not expecting much difference from
the official Mono 2.10 packages for Windows. The XNA, WPF, and msvcm
stuff is not ready yet. So, I know it's kind of crappy right now, and
I'm not asking for testing so much as comments. If you are a packager
of Wine, I would like to make sure you can build it, and that the
resulting build works apart from that deadlock bug.

If for some reason you want to try it, the current version is at
I think I will need a new home for the binaries, because github only
gives me enough space for about 5 of them. So, uh, don't count on that
URL sticking around.

More information about the wine-devel mailing list