[Mono-devel-list] GAC (design) issues
Todd Berman
tberman at sevenl.net
Mon May 3 10:07:57 EDT 2004
On Mon, 2004-03-05 at 09:36 -0400, Joshua Tauberer wrote:
> Ian MacLean wrote:
> > From my understanding of things .net compiler references should
> > *always* be file paths. The assembly probing mechanism is intended for
> > *runtime* resolution of assemblies not compile time references.
>
> Great point.
>
Agreed, this was something that I brought up with jackson a handful of
days ago (believe it or not), however we decided to see what we could do
with just gac references.
The basic issue boils down to this. Having a /usr/lib/net-1.1/ assembly
that mcs uses to resolve is no problem, ship it in the -devel rpms, etc.
No issue. The issue comes with something like gtk-sharp.
Do you put the gtk-sharp libraries in net-1.1 and net-2.0, etc, etc?
If so, that becomes unmanagable really really fast.
So then you say, OK, 3rd party libraries install their stuff
into /usr/lib/LIBRARYNAME-VERSION/ and then somehow tell mcs to probe
that directory for runtime assemblies. To us, that seemed avoidable by
just resolving mcs references out of the gac. It also seems like a
better solution in the long term.
However, if someone can come up with a good 3rd party solution (taking
into account different prefixes and all those permissions issues) I
would love to hear it.
--Todd
> I don't usually speak up on these issues, but is there any reason not to
> do it both ways (actually all four ways)?
>
> It's obviously important (now obvious to me thanks to Ian) to be able to
> reference an assembly by path name. If a /r is an absolute path, look
> for the assembly at that location. This would be compatibile with MS.
> (e.g. /r:/usr/lib/whatever/System.dll)
>
> Next, if the assembly is exactly the name of one of the core framework
> assemblies that MS places in the same directory as csc, load the
> appropriate version of the assembly from the GAC. (The one that
> corresponds to the version of the invoked mcs, or something.) This
> maintains compatibility with MS (and is a nice feature to boot). (e.g.
> /r:System.dll)
>
> Next, if the /r is a relative path, look for the assembly relative to
> the current directory. (e.g. /r:./System.dll or /r:YourAssembly.dll)
>
> Finally, if the /r specifies an assembly name, load it from the GAC with
> the normal GAC rules. (e.g. /r:System[, Version=blah])
>
> In the few minutes I've thought about it, it seems to me it would work
> well and not break anything, and also not require multiple copies of
> anything (provided absolute paths into the GAC work). Apologies if I've
> missed something obvious, of course.
>
> --
> - Joshua Tauberer
>
> http://taubz.for.net
>
> ** Nothing Unreal Exists **
>
>
> _______________________________________________
> 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