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

[A.M. Abdelaziz]

Hi all I solved the problem at last, so again:
The problem is:

   - when compiling with "--with-profile4=yes", monodoc.dll gets compiled
   again with dmcs and replaces the monodoc.dll that was generated first with
   gmcs/mcs (profile 2). When it's compiled with dmcs it won't work because it
   requires features from runtime v4 but it is actually being run by a v2
   runtime.
   - If u changed the AssemblyVersionAttribute to Consts.FxVersion to
   prevent it of being overwritten when compiled again with dmcs, it produces
   two versions 2.0.0.0* and 4.0.0.0* because it gets compiled with mcs/gmcs
   and then dmcs. *That won't work either and I don't know why, it runs fine
   but can't see gnome/gtk docs*.

The solution is:

   - keep *AssemblyVersionAttribute as it is "1.0.0.0"* AND after u finish
   compiling everything navigate to mcs/tools/monodoc/ and compiled again BUT
   with:
      - *make PROFILE=net_2_0 && sudo make install*
   - Now u have monodoc compiled with a profile 2 compiler so it will work +
   its version is 1.0.0.0* so it will see all the documentations u have.

Thanks all, and especially Jon for helping me, I wouldn't solve it without
his help.

On Tue, Jan 5, 2010 at 5:55 AM, A.M. Abdelaziz <amamh3 at gmail.com> wrote:

> > 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.
>
>
> Thanks for this tip !
>
>
> >       * 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).
>
>
> well, that's what I figured out at the end.
>
>
> 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.
>
>
>
> Thanks again, so the whole idea is to separate the two monodoc.dlls so the
> 2.0 one doesn't get overwritten with the 4.0 one.
>
>
> 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
>
>
> Thanks for this tip too.
>
>
> A longer term fix is to make the AssemblyVersionAttribute conditional on
>
> the framework version (e.g. use Consts.FxVersion).
>
>
> here is what I did:
>
>    1. changed AssemblyVersionAttribute to Consts.FxVersion.
>    2. in mcs/tools/monodoc
>       1. make PROFILE=net_2_0 && sudo make install PROFILE=net_2_0
>       2. make PROFILE=net_4_0 && sudo make install PROFILE=net_4_0
>
> now there is two folders in mono/gac/monodoc, a 2.0.0* one and a 4.0.0*
> one, I think the latter has no importance and actually is not used, but it
> won't matter.
>
> now monodoc runs fine but there is something weird:
> I can't see gtk sharp libraries documentation, maybe I have to recompile
> gtk sharp (and hence its documentation) again. I will try and report back,
>  I'm doing an Electronics project now, which I hate :), so I may reply late.
>
> Big Thanks !
>
> --
> A.M. Abdelaziz
>



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