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

[A.M. Abdelaziz]

Thanks for ur expert reply :)
I also didn't know that there are two mscorlib.dll one in mono/2.0/ and
another in /mono/4.0/ 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*.
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"*.

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

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

Thanks all for trying to help me, but this problem seems like it's not
specific to my system, it should happen to anyone using mono from svn.

On Mon, Jan 4, 2010 at 9:33 PM, Jonathan Pryor <jonpryor at vt.edu> wrote:

> Background is below, but the pertinent question for mono-devel-list is
> this: should monodoc.dll follow the framework version numbering scheme
> (Consts.FxVersion) or do something else?  The lack of a
> compiler-dependent version in monodoc is breaking use under the 2.0
> profile.
>
> On Mon, 2010-01-04 at 20:06 +0200, A.M. Abdelaziz wrote:
>
> > both versions print "True" when run by mono from svn or stable mono
> > 2.6.1, but of course the second version (compiled with dmcs) can't be
> > run on mono 2.6.1 because it doesn't support .NET 4, giving a warning
> > of unsupported runtime version then exception of missing method
> > op_Equality in  /usr/lib/mono/1.0/mscorlib.dll then crashes.
> >
> > does that give any insight why monodoc.dll doesn't work from svn, am I
> > the only one having this problem?
> > Thanks in advance
>
> The problem is twofold:
>
>  1. You're building with --with-profile4=yes.
>  2. monodoc only has one version.
>
> So, compare mcs/tools/monodoc/Assembly/AssemblyInfo.cs with
> mcs/class/System/Assembly/AssemblyInfo.cs, and note that monodoc has:
>        [assembly:AssemblyVersion("1.0.0.0")]
>
> while System has:
>
>        [assembly: AssemblyVersion (Consts.FxVersion)]
>
> Which, due to the magic of mcs/build/common/Consts.cs:
>
>        static class Consts
>        {
>        #if NET_4_0 || BOOTSTRAP_NET_$_0
>                public const string FxVersion = "4.0.0.0";
>                // ...
>        #elif NET_2_0 || BOOTSTRAP_NET_2_0
>                public const string FxVersion = "2.0.0.0";
>        #endif
>        }
>
> results (effectively) in a different version number for each different
> compiler version (as each compiler targets a different framework).
>
> Since gacutil is used to install the assembly into the GAC, and gacutil
> uses the AssemblyVersionAttribute value to determine which directory to
> place things into, the result is that, no matter what compiler you use
> to build monodoc, the result will ALWAYS be installed into the same GAC
> directory.
>
> Since you configured with --with-profile4, this means that monodoc is
> built and installed twice, and the last build+install, the net_4_0
> profile, "wins."
>
> The solution is simple: make monodoc use a different assembly version
> based upon which compiler was used to build it (e.g. by using
> Consts.FxVersion, as System/etc. do).
>
> Part of the problem is that monodoc.dll isn't "stable" (it's supposed to
> be for internal use only), which I suppose was why it never used
> Consts.FxVersion.  (Does anyone else have any theory why monodoc never
> used Consts.FxVersion?)
>
> That said, I don't see much reason not to make monodoc follow
> Consts.FxVersion, even if it is unstable and for internal use only...
>
> Thoughts?
>
>  - Jon
>
>
>


-- 
A.M. Abdelaziz
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20100104/e26373ab/attachment.html