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

Jaroslaw Kowalski jaak at zd.com.pl
Sat May 1 05:22:12 EDT 2004


> > +1 to Ian and Gert. We all suffer from NAnt not working on Linux. Fixing
> > nant to deal with the current mono behaviour would be a major hack,
because
> > you can no longer specify system assemblies references in a portable
manner.
> >
>
> How exactly do you do this on ms.net? by setting up your path properly?
> that sounds like the original hack.

No. NAnt eploys the concept of "frameworks". At startup it detects the
available CLI runtimes found on the system (net-1.0, net-1.1, net-2.0,
mono-1.0, sscli, netcf-1.0) and determines (among other things) the path
where all system libraries are located. Now you can have a single build
script and re-target the compilation for a specific platform. Note that you
can compile for some other platform than the one nant is running on. For
example you can run on .NET 1.0 and compile for .NET 1.1 or mono-1.0. NAnt
always feeds the compiler with a list of fully qualified source and
reference names, so that you can have 100% repeatable builds independently
of the PATH settings.

csc.exe doesn't have to be added to the PATH. NAnt is detects it and always
invokes it with a fully qualified path name.

> > Some more issues to consider before shipping v1:
> >
> > 1. AssemblyFolders
> >
> Well, it seems like if a dll is public it should be in the gac.
> and if mcs can resolve libraries out of the gac, then there really isnt a
need
> for this registry + filepath hack.

Yes, it works. If you really want to type:

mcs -r "System.Data, Version=1.0.3300.0, Culture=neutral,
PublicKeyToken=b77a5c561934e089"

each time you compile. OK. I know that mcs can be taught to know to use
"System.Data" with the appropriate version (it's kind-of "core") but it's a
hack.

But what about non-system assemblies like nunit.framework.dll,
NDoc.Core.dll, ICSharpCode.SharpCvsLib.dll, ICSharpCode.SharpZipLib.dll
which come strong-named and in different versions? Are you prepared to type
(actually copy/paste, because you have no chance to remember it) the full
name including the public key token and exact version number?

> So you would prefer we change the default (seemingly sensical) behaviour
> and then add this hack to fix an issue fixed by the current solution?
>

OK. MS.NET developers do it the other way and it does work. IMHO the current
Mono GAC structure will cause more trouble than good.

> > This setup is currently used for Visual Studio to populate "Add
> > Reference..." dialog box. VS.NET stores file references in a portable
manner
> > by storing the name of the assemblyfolder used to find the reference in
> > addition to storing the actual path name. Same thing could be done in
> > MonoDevelop to achieve compatibility.
> >
>
> the name of the assemblyfolder? you mean the registry key it found it in
> i assume.

Yes.

> I dont see how MonoDevelop would maintain that kind of
> portability.

Simple. Same as VS.NET. Assuming the package names will match AssemblyFolder
names there shouldn't be any problem.

> The current thinking for MonoDevelop is pretty simple:
>
> Add a GAC based reference, compile using mcs and it finds it because its
> in the gac. When you go to deploy the package, the configure script
> probes the gac and complains if it cant find the library.
>
> Seems to be pretty easy.

So you're hereby eliminating the possibility of running on MS.NET and using
csc.exe to compile, right? I think that in the future versions of .NET, GAC
might not even be a filesystem-backed store.

> > This way a small "starter" application could be created (simiar to what
> > mscoree.dll does) that would just read the expected mscorlib.dll version
and
> > route to the appropriate mono runtime.

> There is only one runtime as far as I can tell. And the version of the
> libraries that mono attempts to use should be based off the corlib
> version included in your executable, not a config mapping.

I'm not sure if this means "perfect backward compatibility", but I may be
wrong. If I'm right though, it means the dependency hell is likely to arise.
Remember that the runtime itself can have issues which some applications
will rely upon which will ultimately break them when the runtime is "fixed".

> Again, I dont understand why Gert needs to reference these assemblies
> explicitly, and if he does, why $PREFIX/mono/$VERSION/$ASSEMBLYNAME is
> any easier than
> $PREFIX/lib/mono/gac/$ASSEMBLYNAME/$VERSION__$PUBTOKEN/$ASSEMBLYNAME .
> (Other than it obviously being easier to type).

GAC is not a filesystem and shouldn't be treaded as such. Ideally the MS
should have encrypted the contents of "\Windows\assembly\GAC" folder or put
it into a ZIP file in the past.

BTW. Under .NET GAC has a special semantics: assemblies from the GAC are
"shared" among appdomains in a single process. It introduces a performance
hit when accessing static data but helps in preserving memory since only one
copy of each routine is JITted. Is mono going to implement this feature? Do
you think the GAC as it's implemented will fit this idea?

Jarek




More information about the Mono-devel-list mailing list