[Mono-dev] Using mdoc for internal documentation

[Casey Marshall]

On Apr 7, 2009, at 7:08 PM, Jonathan Pryor wrote:

> On Tue, 2009-04-07 at 17:54 -0700, Casey Marshall wrote:
>>> `foo.dll' is an assembly I've built (forgive the obfuscation). It's
>>> typically a very "core" assembly, i.e., one very high up in the
>>> dependency tree, and most certainly is in the same directory as the
>>> assembly depending on it, and is being specified on the command  
>>> line.
>>>
>>> In fact, I was really surprised that it was complaining about not
>>> finding that assembly, since it is such a central one.
>>>
>>
>> WRT this, it seems like somehow mdoc is trying to look up the
>> "qualified" (or whatever) name, which includes the Version=1.0.0.0,
>> PublicKeyToken=XXX, et al. Cecil seems to just try name + ".dll" and
>> name + ".exe", which obviously won't work.
>
> It should work...within reason, as the qualified assembly name will  
> (by
> necessity) include the file's base name, e.g. 'mscorlib,
> Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'  
> must
> be located within an assembly having 'mscorlib' as the basename.
>
> Now, that (obviously) can't be the only check -- after finding an
> assembly with a matching basename it'll need to check that the  
> version,
> culture, and PublicKeyToken of the found assembly are correct (and if
> not correct continue looking for the next one), but as a start it  
> should
> be fine.
>
> Which leads to the next question: where is 'foo.dll' located?  In a  
> path
> on the command line, e.g. 'mdoc update path/to/foo.dll'?
>

foo.dll is in the directory bin/Debug, and so is the assembly I'm  
documenting (call it bar.dll), which depends on foo.dll.

> Or is foo.dll in the GAC?
>
> Or is foo.dll in MONO_PATH, e.g. 'MONO_PATH=/tmp mdoc update ...'?
>
> For the first two cases (command line and GAC), Cecil *should* be
> finding the assembly (otherwise we couldn't resolve IEnumerable<T> and
> other mscorlib types, and I know I fixed a bug related to the first  
> case
> that the Gendarme build process was encountering).
>
> MONO_PATH, as mentioned before, isn't currently supported (as it  
> hadn't
> even occurred to me to support it).  If 'foo.dll' is in MONO_PATH,  
> could
> you try using the patch I applied to the previous email and see if  
> that
> fixes the issue?
>

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". The  
directory `foo.dll' (along with everything else) is in, bin/Debug,  
doesn't get added to that resolver. It's a different object than the  
one that AddSearchDirectory is called on in monodocer.cs.

Thanks.