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

[Jonathan Pryor]

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