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

[Todd Berman]

Allright, ill bite. comments/questions inline.

On Sat, 2004-01-05 at 10:02 +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.

> Some more issues to consider before shipping v1:
> 
> 1. AssemblyFolders
> 
> Having an established system for AssemblyFolders would be great to have on
> mono, too. This would make dealing with installed mono-dependent
> applications/libraries much easier and would help in porting Visual
> Studio.NET solutions to Mono (using for example nant's <solution> task).
> 
> The idea:
> 
> Every application package installs its public dlls (to be used for
> compilation) in some place and puts the path information in a well-known
> place.
> 

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.

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?

> This would be similar to:
> 
> HKLM\Software\Microsoft\.NETFramework\AssemblyFolders
> HKLM\Software\Microsoft\\VisualStudio\7.0\AssemblyFolders
> HKLM\Software\Microsoft\\VisualStudio\7.1\AssemblyFolders
> 
> HKCU\Software\Microsoft\.NETFramework\AssemblyFolders
> HKCU\Software\Microsoft\\VisualStudio\7.0\AssemblyFolders
> HKCU\Software\Microsoft\\VisualStudio\7.1\AssemblyFolders
> 
> 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. I dont see how MonoDevelop would maintain that kind of
portability.

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.

> BTW. Note that VS.NET doesn't display GAC assemblies in "Add Reference...",
> as you cannot reference a file in the GAC while compiling.
> 
> On unix the structure used to keep this package information would be:
> 
> /etc/mono/packages.d/ - for system version-neutral packages
> /etc/mono/1.0/packages.d/ - for system version-specific packages
> /etc/mono/2.0/packages.d/ - for system version-specific packages
> ~/.mono/packages.d/ - for user version-neutral packages
> ~/.mono/1.0/packages.d/ - for user version-specific packages
> ~/.mono/2.0/packages.d/ - for user version-specific packages
> 
> Each directory would hold XML description files:
> 
> <package>
>     <name>package1</name>
>     <description>Some package1</description>
>     <version>0.0.1</version>
>     <assemblyfolder>/opt/somepackage/lib</assemblyfolder>
> </package>
> 
> A tool could be created that would manage files stored in this manner,
> similar to "pkgconfig".
> 

I guess to me, this whole 'AssemblyFolders' concept seems to be a hacky
workaround to the fact that csc can't resolve out of the gac.

If the only reason you think we need to match the (In my opinion) broken
MS behaviour is to allow loading of different .net framework versions,
it seems like it would be simple to allow some env variable to specify
the corlib to use (that is the important assembly that determines the
other assembly versions for MCS). I assume martin and jackson have some
plan in the works for how to specify the corlib to run/build against,
and I dont know what it entails, but I am sure it will allow this.

> 2. Framework mapping
> 
> I also think that it would be convenient to see a
> framework-version-to-mono-version mapping defined in some public and
> unmovable place. It would be reused across mono versions (like
> /etc/mono/frameworks.conf)
> 
> v1.0.3750 -> 1.0
> v1.1.4322 -> 1.1
> v2.0.3600 -> 2.0
> 
> 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.

> 3. Flat "framework" structure
> 
> I would refine Gert's idea of filesystem layout. I personally see no reason
> to thave "mcs.exe" in the "bin" directory while the rest goes into "lib"
> directory.
> 
> I'd love to have each framework installed in a separate flat directory,
> where all the compilers and core libraries would go:
> 
> $PREFIX/mono/1.0/
> $PREFIX/mono/1.1/
> $PREFIX/mono/2.0/
> 
> This simple setup would solve all the issues Gert mentioned.
> 

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

The only additional piece of info needed is the pubtoken, and that isnt
likely to change due to compatability with ms, and if it is different, I
doubt it will change on our end all too often. (assuming here).

Just as a bit of a disclaimer, I am kinda sure about most of this, but
not 100%, mainly asking these questions because I don't quite understand
the real problem.

--Todd