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

[latency]

On Sunday 17 December 2006 14:54, you wrote:
> If you have an svn account, you can add the files at any time.
> Otherwise, you need to wait until one of us has a chance to update svn.

No I don't have one. So I just pull some Tea and wait for the changes to 
happen.


> This also requires updating the monodoc build process.  Currently it
> uses monodoc/generator/updater.exe, while it needs to use
> monodocer/tools/monodocer.exe, as monodocer.exe supports generics while
> updater.exe doesn't.
>
> This change is trivial.
>
> What is less trivial is that we want to separate the .NET 1.1 docs from
> the .NET 2.0 docs.
>
> This is also trivial -- add ``-since:".NET 2.0"'' to the monodocer
> command line, and any added types/members will get a <since/> element
> added with the specified value.  If we assume that the previous docs
> only contain 1.1 docs (and *all* of the 1.1 docs), then this works
> fairly well.
>
> This could all be done now, actually, but I had been holding off on
> doing it as I wanted to change monodocer so that it could import the
> ECMA 335 documentation, as ECMA 3rd Edition (and now 4th Edition)
> contains documentation for many of the generic types/members, and we'd
> like to make use of this.
>
> However, as per discussion with miguel earlier last week, we currently
> plan to always overwrite the existing docs with the new docs when
> importing ECMA docs, so there is no reason to wait on updating the
> monodoc/class docs for this new support.
>
> Given this, I'll try to get updated docs committed to svn some time this
> week, and work on the monodocer support later.

Is the current documentation, including all user contributions for the 1.1 or 
2.0 version of the framework? Will the current contributions survive the 
change of the build process?

And in I my opinion this concept should be extended to meet the version 
changes of third-party assemblies that are shipped with mono as well. Because 
if we only distinguish between .Net 1.1 and 2.0 third-party assemblies can 
not be documented in a way where users see in which version of the assembly 
the api has been changed.


> This is correct, SWF would need to be added to the build process of
> monodoc.  We really should make sure that all assemblies included with
> mono are part of monodoc as well.

I've taken a look into it and this should be the list of assemblies to add:
(These are all assemblies that I've found in the GAC of a newly compiled mono 
which are not present in monodoc. But I guess the assemblies still under 
development like System.Transactions can be removed from the list.)

- Accessability
- CustomMarshalers
- FireBird
- l18n
- IBM.Data.DB2
- SharpZipLib
- Microsoft.Build.*
- Mono.C5
- Mono.Data.* (currently only SqlClient is included)
- Mono.Http
- OpenSystem.C
- PEAPI
- System.Design
- System.EnterpriseServices
- System.Management
- System.Messeging
- System.ServiceProcess
- System.Transaction


> mdassembler is a script which executes assembler.exe:
>
> 	#!/bin/sh
>
> 	prefix=/usr
> 	exec_prefix=${prefix}
> 	monodocdir=/usr/lib/monodoc
>
> 	exec /usr/bin/mono $monodocdir/assembler.exe "$@"
>
> So it's easier for everyone to use.

I've found that out by myself 5 minutes after I sent the mail. But still 
thanks for the answer :-)

Kind Regards,
Valentin S.