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. _______________________________________________ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list