[Mono-dev] Mono gac vs Multi gac

[Andres G. Aragoneses]

In case anyone was interested in this thread, there was a fix much 
simpler than adding policy files: runtime mapping.

So, this is very handy to know: 
https://github.com/mono/mono/commit/e3b9881e5707953bd37fb3ed0dbeab93e6603a5e


On 14/10/12 21:37, Andres G. Aragoneses wrote:
> 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...