[Mono-list] Fwd: monodoc.dll looking for missing method in mscorlib.dll

[Jonathan Pryor]

On Tue, 2010-01-05 at 00:10 +0200, A.M. Abdelaziz wrote:

> I also didn't know that there are two mscorlib.dll one in mono/2.0/
> and another in /mono/4.0/

There would be 3, as the 1.0 mscorlib.dll is also different, but we
dropped 1.0 profile support for 2.8.

>  and when comparing with gui-compare I found that the 2.0 one does
> miss the method Type.op_Equality which does exist in the 4.0 one.

Your logic is right, but the phrasing is wrong: Type.operator== was
*added* in 4.0.  Consequently, you can't take code compiled against 4.0
and run it under 2.0 (just as you can't take code compiled against 2.0
and run it under 1.0).  Backward compatibility doesn't run backwards.

> I couldn't modify mcs/tools/monodoc/Assembly/AssemblyInfo.cs to change
> its AssemblyVersion attribute to Consts.FxVersion the compiler always
> complained about unidentified variable "Consts", so I changed it to
> "4.0.0.0".

This is because Consts.cs isn't in the build script.  You can
add ../../build/common/Consts.cs to
mcs/tools/monodoc/monodoc.dll.sources and the Consts type will be
available.

> My conclusion/understanding is :-
>       * The last compiler who compiled monodoc.dll is dmcs because of
>         "--with-profile4=yes" so it produced bytecode that requires
>         features from 4.0 runtime

Yes.

>       * In the AssemblyInfo.cs it says it needs runtime version
>         1.0.0.0 so when it was run with mono, it loaded the right
>         mscorlib.dll for the required runtime which is
>         mono/2.0/mscorlib.dll, so the problem arises.

No.  The AssemblyVersionAttribute doesn't say what runtime version it
targets.  It specifies the version of the assembly itself (monodoc.dll
in this case).

Since we were compiling the assembly twice with the same version number
each time, gacutil was installing both of them into the same directory.
If the separate builds had different version numbers, they'd be
installed into different GAC directories.  Hence using Consts.FxVersion
would be *a* fix for this.

It wasn't a fix for you (below) because you kept using the 4.0 compiler
to create an assembly that needs to be used in a 2.0 app; you needed to
use the 2.0 compiler.

>       * Now the AssemblyVersion attribute is set to 4.0.0.0 so it
>         _should_  use  mono/4.0/mscorlib.dll so it will run fine.
> well I have just (right now just before I write this statement)
> finished compiling and installing.
> After the changes:
> running "monodoc" again crashes, it still uses mono/2.0/mscorlib.dll
> which doesn't has the required method so it crashes.
> It seems that modifying AssemblyVersion attribute resulted only in:
>       * there is a new folder named "4.0.0.0__0738eb9f132ed756" in
>         gac/monodoc beside the old one that existed before
>         "1.0.0.0__0738eb9f132ed756"
>       * "monodoc" still uses monodoc.dll in
>         "1.0.0.0__0738eb9f132ed756".
>       * overwriting monodoc.dll in the 1.0.0.0_~ with the one from
>         4.0.0.0_~ doesn't fix the issue, it's also referencing
>         2.0/mscorlib.dll and not 4.0/mscorlib.dll

Right.  This happens because you never rebuilt and installed monodoc
against the 2.0 compiler.

> So the question is:
> How can I make monodoc.dll reference the right mscorlib.dll based on
> which compiler compiled it?
> the right mscorlib.dll for me is the one in 4.0/mscorlib.dll since I
> used "--with-profile4=yes" so dmcs is the compiler who compiled
> monodoc.dll

But this is, in fact, the wrong compiler.  It's the wrong compiler
because monodoc (the app) was built against gmcs (see mono-tools).  Thus
when it runs, it'll be started as a 2.0 app, which won't be able to add
4.0-specific members, which is *exactly* the scenario you're in.

So a temporary fix is simple:

     1. Undo all your changes to monodoc.dll
     2. cd mcs/tools/monodoc
     3. make PROFILE=net_2_0
     4. make PROFILE=net_2_0 install

This should ensure that $prefix/lib/mono/gac/monodoc/1.0*/monodoc.dll
was built against a 2.0 compiler, which will thus allow monodoc (the
app) to load w/o error.

A longer term fix is to make the AssemblyVersionAttribute conditional on
the framework version (e.g. use Consts.FxVersion).

 - Jon