[Mono-devel-list] GAC issues and third party libraries.

Miguel de Icaza miguel at ximian.com
Wed May 5 13:36:22 EDT 2004


> > 	* For gtk-sharp in particular (since its a big app of ours),
> > 	  instead of installing it into the "gtk-sharp" child of
> > 	  lib/mono (ie, lib/mono/gtk-sharp), install it on the
> > 	  lib/mono/1.1, so we would get it by "default".
> Why can't /package always put dlls in lib/mono/ and not in
> lib/mono/NAME/? If it's about name conflicts, then what's the difference
> between name conflicts between directories and dlls themselves?

My concern is linked to shipping two profiles: the 1.0 with the standard
compiler, and the 2.0 with the generics compiler, but this problem in
general is bigger if we consider the 1.0, 1.1 and 2.0 profiles.

For Mono 1.0 we are abandoning the idea of shipping a .NET 1.0 profile,
and the 2.0 profile is shipping under a `at your own risk' mode.

So we need the input from people like you (compiler developers) and
library developers to better understand how to solve this problem.

One option is to always create the links in prefix/lib/mono/1.0 to the
gac-ed version of the assembly for this release, so every library
installed is available for development as well.

But we need to start thinking about what will happen in future versions.

As you might have noticed, the mcs script ships with a hack (a horrible
one): it always adds the gtk-sharp directory, it was done for two reasons:

	* To not break existing Makefiles that do:

		mcs program.cs -r:gtk-sharp

	* If we decided to change our mind, and put everything in
	  the prefix/lib/mono/1.0 or not, we could still have control
	  of it.

We do not have a good answer yet, and I would love if we could discuss
this during this week and the next, and find an optimal solution.

Am posting on a separate message another iteration over the idea.


More information about the Mono-devel-list mailing list