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 lookslike the assembly resolver being used (a DefaultAssemblyResolver) onlyhas 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 havecooked 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!
mdoc.patch
Description: Binary data
_______________________________________________ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
