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

Todd Berman tberman at sevenl.net
Fri May 28 10:08:18 EDT 2004


and i will annotate my own reply, as there is a tiny piece of incorrect
info.

On Fri, 2004-28-05 at 10:02 -0400, Todd Berman wrote:
> 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

$prefix/lib/mono/gtk-sharp-1.2/gtk-sharp.dll, not /gac/ dir. duh.

> 
> 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
> 
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list




More information about the Mono-devel-list mailing list