[Mono-devel-list] GAC Information and Assembly Versioning

[Todd Berman]

This is pretty much on, I will try and add comments inline to where
there is more info available.

On Fri, 2004-28-05 at 07:43 -0400, Jonathan Pryor wrote:
> I apologize profusely for even mentioning the GAC again, as every time
> it comes up a large thread is spawned...  I fear this will be no
> different.
> 
> First, is there any public document describing the current GAC system,
> it's aims, how it works, and how to use it?
> 
> In a sense, the first part of this email is an attempt at documenting
> some of this, to ensure that (1) I understand what's going on, and (2)
> the current situation will actually be documented.
> 
> The second part asks a question regarding the current setup and
> interaction with assembly versions.
> 
> At present, the GAC directory structure appears to be:
> 
> 	$prefix/lib/mono/<assembly-name>/<assembly-version>/<files>
> 

In fact, the setup is $prefix/lib/mono/gac/<assembly-name>/<assembly-
version>_<assembly-culture>_<assembly-publickeytoken>/<assembly-name>.
dll

because most assemblies have a neutral culture, they are inserted
without a culture string so you end up with __.

Notice that at the end it is <assembly-name>.dll. This is a bit
different than what you might expect.

MCS assigns the assembly name based on the -out: parameter to your
compile command, however, you can always rename it later to something
else. If you created gaclib.dll, renamed it somethingelse.dll and put it
in the gac, it would show up as gaclib.dll, not somethingelse. Not
normally something to worry about, but just more info.

> For example, Gtk# is installed in
> 
> 	/usr/lib/mono/gac/gtk-sharp/1.0.0.0__35e10195dab3c99f/gtk-sharp.dll
> 
> To compile against Gtk#, we can either explicitly use pkg-config:
> 
> 	mcs my-app.cs `pkg-config --libs gtk-sharp`
> 
> Or we can use the new -pkg mcs flag:
> 
> 	mcs my-app.cs -pkg:gtk-sharp
> 
> Which is analogous to the above.
> 
> Pkg-config, in turn, refers to files located in:
> 
> 	$prefix/lib/pkgconfig/<assembly-name>.pc
> 
> In the case of Gtk#, /usr/lib/pkgconfig/gtk-sharp.pc.
> 
> The pkg-config (.pc) file in turn contains both the required assembly
> reference arguments (-r:glib-sharp, etc.) and directories to add for the
> search path (-lib:/usr/lib/mono/gtk-sharp).

The current pc files directly reference the symlinks, as 5 /r:s with
full path are faster than one /lib and 5 /r's with just a dll name.

so for gtk-sharp my Libs: line looks like:

-r:/usr/lib/mono/gtk-sharp/glib-sharp.dll -r:/usr/lib/mono/gtk-sharp/
pango-sharp.dll -r:/usr/lib/mono/gtk-sharp/atk-sharp.dll -r:/usr/lib/
mono/gtk-sharp/gdk-sharp.dll -r:/usr/lib/mono/gtk-sharp/gtk-sharp.dll

A bit long looking, but since this is something you dont have to deal
with directly, it works out fine.

> 
> What's in the library search path?  Symbolic links from:
> 
> 	$prefix/lib/mono/<project-name>/<assembly-name>.dll
> 
> which refer to the actual files within the GAC.  Project-name is a new
> construct, grouping related assemblies within the same project.  For
> example, the "gtk-sharp" project contains symbolic links for
> art-sharp.dll, atk-sharp.dll, gdk-sharp.dll, glad-sharp.dll,
> glib-sharp.dll, gtk-sharp.dll, and pango-sharp.dll.  Project-name could
> also be the assembly-name, if the project contains only one assembly.
> 

Actually, there are a lot more things installing into the gtk-sharp
'package' currently. In addition to gnome, gconf, etc, right now gecko-
sharp and gtksourceview-sharp also go there. Part of this was the need
to use them before -pkg was ready, and part of this was that it just
makes sense.

> All of this appears to be the case for CVS so far.
> 
> Now, the question: how do we handle development against multiple
> assembly versions?  Todd Berman first asked this on May 11, and I didn't
> see anything that directly answered his question, and the problem didn't
> occur to me until recently.
> 

That is actually pretty easy.

Gtk# 1.0 installs all its pc files, dlls, etc, the way it does now. Then
Gtk# 1.2 comes along, and names its pc files and 'package' gtk-sharp-1.2
or whatever. You would end up with:

$prefix/lib/pkgconfig/gtk-sharp-1.2.pc

and

$prefix/lib/mono/gac/gtk-sharp-1.2/gtk-sharp.dll

which would be a symlink to the 1.2 assembly in the gac.

This would allow a developer who wants to compile against the 1.2
libraries to just pass -pkg:gtk-sharp-1.2 to mcs.

Gtk# 1.0 and 1.2 would then become parallel installable.

So both developers and users would be set at both runtime, and compile
time.

--Todd

> When Mono 1.0 is released, Gtk# 1.0 will also be released.
> 
> When Gnome 2.8 is released in September, Gtk# 1.2 will likely be
> released.  (Last I heard, Gtk# would try to follow the Gnome Language
> Bindings schedule after 1.0, which is tied to the Gnome schedule.)
> 
> Consequently, before the end of the year we're likely to have two
> different (and upwardly compatible) versions of Gtk# installed on our
> machines.
> 
> What happens if we want to develop against *both* of them?  It's
> entirely plausible that developers will have both versions installed,
> but users will have a mix between the two, with some users sticking to
> Gtk# 1.0 because they don't have GTK+ 2.4 yet (slow Red Hat 9 users, for
> example).
> 
> Since the current use of pkg-config presently ignores versions, as the
> -lib directory is unversioned, how do we handle this development
> scenario?  It seems that we could only have one Gtk# development package
> installed at a time.
> 
> This might not be too bad, as GTK+ can only have one development version
> installed at a time, IIRC.  (That is, you can't have GTK+ 2.2 and GTK+
> 2.4 development packages installed at the same time, as the header files
> will conflict with each other.  Furthermore, some of the headers have
> changed between the versions, preventing code compiled against the GTK+
> 2.4 headers from running on a GTK+ 2.2 system.)
> 
> Alternatively, we could version the pkg-config files, resulting in
> gtk-sharp-1.0.pc and gtk-sharp-1.2.pc, and each could refer to a
> different, versioned, directory in the -lib: argument.  However, this
> might be non-obvious, as the command:
> 
> 	mcs my-app.cs -pkg:gtk-sharp-1.0
> 
> would generate assembly references to gtk-sharp.dll.
> 
> Do we want to support development against multiple assembly versions? 
> If so, how should we support it?  We should probably solve this before
> Mono 1.0 is released, as we'll likely run into these issues before Mono
> 1.2 is shipped at the end of the year.
> 
>  - Jon
> 
> 
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list