[Mono-devel-list] GAC (design) issues

Charlie Poole cpoole at pooleconsulting.com
Mon May 3 11:15:52 EDT 2004

Gert wrote:

> Always using fully qualified assembly names is not an option, 
> and for Mono, we would not be able to search for an assembly 
> in the framework assembly directory, as there would no longer 
> be such a dir (all system assemblies are in the GAC), and we 
> can't scan the GAC as that would mean we'd have to guess too ...
> And we can't just determine the fully qualified assembly name 
> of a given assembly file, as you could have NAnt running on 
> NET 1.0 while targeting and referencing a .NET 2.0 assembly. 
> Meaning we wouldn't even be able to load the assembly ...

One of the tools using this capability is NUnit. Our latest build script
targets .NET 1.0, .NET 1.1 and mono. In the near future we'll add .NET
2.0 (yes, we did give mono priority over 2.0) and the compact framework.
Eventually, I expect there will be multiple mono versions which we will
need to support. Contributors should be able to work under whichever of 
those they find most convenient. If they're on a win32 machine, they 
should be able to build under mono and then test under the various
alternative platforms.

I'm making no statement about whether the above is possible under your
implementation, but from what I'm hearing I'm getting worried. It seems 
to me that a list of statements like the above - outlines of acceptance 
tests, in fact - would go a long way toward clarifying what the mono 
developers are intending in relationship to what some of us are hoping

On a more general note, I'd guess that the discussion about transparent
access to the gac versus use of file paths already took place among the
ms developers. They ended up with a compromise that keeps the gac
out of the file system, while requiring that development tools need
a copy to function have one available. What's wrong with that? If you
don't want to provide "extra" copies of the system assemblies in the
default installation, you could still provide a script that "exports"
them for those tools needing this treatment. That way, developers who
are not mono hackers could simply pretend that they didn't know where
you keep the gac - it might not even be a pretense, in fact. :-)


Charlie Poole
cpoole at pooleconsulting.com

More information about the Mono-devel-list mailing list