[Mono-docs-list] Fwd: [Mono-winforms-list] Exception when using monodocer on System.Windows.Forms.dll

Miguel de Icaza miguel at ximian.com
Mon Dec 18 16:35:13 EST 2006


> Thus, I propose the following: Change monodoc/class/Makefile.am's
> `update' target to be:
> 
> 	update:
> 		for a in $(UPDATE_ASSEMBLIES); do \
> 			mono --debug ../tools/monodocer.exe \
> 			../../mcs/class/default/$a ;
> 		done
> 		for a in $(UPDATE_ASSEMBLIES); do \
> 			mono --debug ../tools/monodocer.exe \
> 			../../mcs/class/net_2_0/$a ;
> 		done
> 
> That is, when updating run monodocer.exe *twice*, once against the 1.0
> assembly, and once against the 2.0 assembly.
> 
> This makes the assumption that when a member is added it's added to the
> appropriate versions (e.g. if it's a 1.1 member we're adding it's also
> added to the 2.0 profile as well), which is a fairly sane assumption.

Agreed.  This looks sane.

We have discovered something in Moma that is probably important to look
into.   

In 2.0, a number of new overrides were done, for example, consider
Windows.Forms' Button override for OnMouseEnter:

           protected override void OnMouseEnter (EventArgs e)

This method which was introduced in 2.0 matter only from the
compiler/reflection standpoint (ie, you generate a reference to
Button.OnMouseEnter instead of Control.OnMouseEnter which is where the
method was originally defined).

The issue here is how to properly flag a method as being a 2.0 feature
or not.    Because *source code wise* (and this is what Monodoc should
document, and this is how MSDN documents it) the source code is
compatible since OnMouseEnter existed in the 1.1 profile.

So now the question is: how do we implement this feature?

Miguel.



More information about the Mono-docs-list mailing list