[Mono-dev] Mono gac vs Multi gac

Andres G. Aragoneses knocte at gmail.com
Sun Oct 14 20:37:37 UTC 2012


Hello Miguel, thanks for your fast (unlike mine) reply.


On 08/10/12 13:34, Miguel de Icaza wrote:
> Hello Andres,
>
> This is indeed a challenging question.
>
> When Microsoft runs the "gacutil" command, once per version and lists a
> single assembly, it looks really like the equivalent of Mono being
> installed in separate prefixes, it is almost as if none of the different
> versions are aware of the other assembly versions installed in the system.

Yes, but at runtime it acts like if it had policy files (to redirect 
load requests of old versions of DLLs to load new versions). But I don't 
find their policy files... So I'm not sure how they do it. (Because I 
tested installing a FooLib2.0 in the GAC, create a BarProgram that links 
to a it, and then replace FooLib2.0 with FooLib3.0 in the GAC, and 
there's no automatic redirection, a FileNotFoundException is thrown...)


> The first question is whether there is a workaround that will work for
> you, or other developers in your situation, because that seems like an
> unobtrusive way of solving this problem, without making changes that
> would affect too many parts of the code base.

I would have hoped that by installing only the profile I'm interested in 
(via --with-profile2=no --with-profile4=yes --with-profile4_5=no when 
calling autogen.sh) worked, but given the above doesn't work neither in 
.NET or Mono (no automatic redirection even when there are no other 
versions of the library).

So I guess the real workaround is just making sure there are no 
libraries linked against different .NET versions... Which is especially 
hard to do when you're consuming things out of your control (like 
libraries from nuget, which is our case; but oh well, at least we have 
the sources and can recompile, otherwise IL replacement would have been 
much harder/cumbersome...).


> The second question is whether it would be enough to provide a policy
> file that forwards 3.5 requests to 4.0 requests.  Like we did for Gtk#

That's interesting, I had already discarded the idea because .NET 
doesn't seem to do this. For Gtk# it makes (made) sense because having 
different versions of it installed at the same time would not make much 
sense*, but in this case it makes sense: what if both the program and 
the lib are compiled against the 2.0 profile (and thus the mono 
executable loads the 2.0 runtime by default when being invoked), but 
policy files define it should load a 4.0 lib, then there is a problem... 
unless, there is a way to blacklist this scenario?

Hmm, and I just looked on <assemblyRedirect> docs, and it seems there is 
a way: the "appliesTo" attribute [1], right? Should I go ahead to try to 
implement this fix?


Regardless, this would not fix the fact gacutil returns all versions of 
the libraries. I guess the correct fix for this is to change this folder 
structure:

$prefix/lib/mono/gac
                    \_ S.R.Serialization
                           \_ 2.0.0.0__d39084jdijc39993
                           \_ 4.0.0.0__b77a5c561934e089
                    \_ ...

To this:

$prefix/lib/mono/gac
                    \_ 4.0
                          \_S.R.Serialization
                                 \_ 4.0.0.0__b77a5c561934e089
                          \_ ...
                    \_ 2.0
                          \_S.R.Serialization
                                 \_ 2.0.0.0__d39084jdijc39993
                          \_ ...
                    \_ ...

Then, make gacutil point to 4.x by default, and provide convenience 
scripts like "gacutil2" that call it with the --gacdir argument to point 
to 2.0?

I guess you are going to ask me what would that fix apart from being 
closer to .NET, and I would agree, but nevertheless still interested in 
what you think about this approach.

Thanks,

   Andres


[1] http://msdn.microsoft.com/en-us/library/433ysdt1%28v=vs.71%29.aspx

* Except maybe when Gtk#3.0 is soon released, but that's another 
discussion...




More information about the Mono-devel-list mailing list