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

[Todd Berman]

On Sat, 2004-01-05 at 11:22 +0200, Jaroslaw Kowalski wrote:
> > > +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.

My understanding of how it does that is by probing the registry, and by
some Nant.exe.config file. I assume that gives it the ability to set an
environment variable or something similar that would alleviate this
problem on the mono runtimes, as it *already* special cases each
runtime.

> 
> 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.

Its no more of a hack than Assembly.LoadWithPartialName. The idea is
that if you dont care what version you get, you get the latest, if you
do, then make mcs know about it. And I might be completely wrong, but I
think System.Data,Version=1.0.3300.0 is enough.

> 
> 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?
> 

A) people build from makefiles, that solves the need to paste and/or
remember it.
B) Most of the time I am going to want the latest version of these
assemblies.

> > 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.
> 

I personally think this is an implementation detail, and if it ends up
working the same to the end user/developer it shouldnt matter. All of
what I have heard so far, there is still no answer given for exactly
*why* nant needs to be able to physically ref the exact files.

> > > 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.

Exactly how would such compatibility be achieved on a linux system with
no registry?

> 
> > 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.
> 

I am for the foreseeable future. MonoDevelop *REQUIRES* a host of other
libraries that are nowhere near ready for the windows platform. We need
a full gnome stack installed to run properly. I don't see that happening
any time soon, as it is yet to happen at all so far. I think writing
compatibility support for something that is not likely to occur any time
soon is not a good idea, and really a misuse of developer time.

> > > 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, this seems to be moot. If your application was built with a 1.1
runtime, it should use those libraries on mono. If it was built with a
2.0 runtime, it should use those libraries. Where is the dependency
hell? Seems like it doing the right and smart behaviour.

> > 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.
> 

As miguel pointed out, Our gac is. and as you said above, NAnt already
special cases each and every one of the platforms. So whats the problem
with it changing its mono special case?

--Todd