[Mono-dev] Using mdoc for internal documentation

Casey Marshall casey.s.marshall at gmail.com
Thu Apr 9 15:56:05 EDT 2009


On Apr 8, 2009, at 2:36 PM, Jonathan Pryor wrote:

> On Wed, 2009-04-08 at 13:37 -0700, Casey Marshall wrote:
>> I don't think that will fix it — I dug around with mdb and it looks
>> like the assembly resolver being used (a DefaultAssemblyResolver)  
>> only
>> has the default directories in the search path, "." and "bin".
>
> This is exactly what I needed to know.  I didn't realize that each
> assembly would have a different Resolver... :-(
>
> In any event, I was (eventually) able to reproduce the problem, and  
> have
> cooked up the attached patch which appears to fix it for me.
>
> Hopefully this will fix things for you.
>

Nope. At least, it doesn't if I run monodoc like this:

   mdoc update --out=generated-docs --import=xmldoc/bar.xml bin/Debug/ 
bar.dll

...and don't specify all the .dlls that foo.dll links to on the  
command line. From my understanding of things, the patch wouldn't fix  
this, since an assembly could still get constructed outside the method  
modified there, and thus with a default resolver instance.

If I add all the assemblies involved to the command line, I get  
undocumented entries for all the members of those assemblies, since  
I'm not giving any --import options for their XML doc files. So, I'd  
rather not do it that way.

I applied the attached patch, and it seems to fix this for me. This is  
probably wrong for various reasons, but it helps me get docs  
generated. What the patch does is use the idea of a static  
DefaultAssemblyResolver, and it falls back to that one if  
`type.Module.Assembly.Resolver' didn't look up the type successfully  
in DocUtils.GetTypeDefinition.

Thanks!

-------------- next part --------------
A non-text attachment was scrubbed...
Name: mdoc.patch
Type: application/octet-stream
Size: 1598 bytes
Desc: not available
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20090409/de6518df/attachment.obj 
-------------- next part --------------



More information about the Mono-devel-list mailing list