[Mono-dev] Using mdoc for internal documentation
casey.s.marshall at gmail.com
Wed Apr 8 16:37:37 EDT 2009
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
>>> 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=188.8.131.52,
>> 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
> necessity) include the file's base name, e.g. 'mscorlib,
> Version=184.108.40.206, Culture=neutral, PublicKeyToken=b77a5c561934e089'
> 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
> culture, and PublicKeyToken of the found assembly are correct (and if
> not correct continue looking for the next one), but as a start it
> be fine.
> Which leads to the next question: where is 'foo.dll' located? In a
> 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
> that the Gendarme build process was encountering).
> MONO_PATH, as mentioned before, isn't currently supported (as it
> even occurred to me to support it). If 'foo.dll' is in MONO_PATH,
> you try using the patch I applied to the previous email and see if
> 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.
More information about the Mono-devel-list