I'm trying to use mdoc, along with the monodoc asp pages and the
monodoc browser, to deploy some internal API documentation. I'm having
trouble getting it to produce documentation for all our assemblies
(80, which will grow to more than 100).
I had been using `monodocer' in previous releases
On Mon, 2009-04-06 at 17:06 -0700, Casey Marshall wrote:
> Sometime ago, though, it looks like `monodocer' became an alias for
> `mdoc update'. I'm having trouble getting mdoc-update to do the right
> thing.
This happened with Mono 2.0.
> I tried this, in makefile syntax (DOC_TARGETS is a lis
On Apr 6, 2009, at 8:56 PM, Jonathan Pryor wrote:
> On Mon, 2009-04-06 at 17:06 -0700, Casey Marshall wrote:
>> Sometime ago, though, it looks like `monodocer' became an alias for
>> `mdoc update'. I'm having trouble getting mdoc-update to do the right
>> thing.
>
> This happened with Mono 2.0.
>
On Apr 7, 2009, at 4:06 PM, Casey Marshall wrote:
> On Apr 6, 2009, at 8:56 PM, Jonathan Pryor wrote:
>
>> Also, what is 'foo.dll'? Is it a library that you built, or a
>> GAC-located assembly? If you're using Mono 2.4, Cecil will only
>> check
>> the GAC and the directories of assemblies spec
On Tue, 2009-04-07 at 16:06 -0700, Casey Marshall wrote:
> Another common thing I'll see is this, using `mdoc update':
>
>mdoc: The node to be removed is not a child of this node.
>See `mdoc help' for more information.
>
> There doesn't seem to be any way to tell mdoc to print internal
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 o
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
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
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
On Thu, 2009-04-09 at 12:56 -0700, Casey Marshall wrote:
> 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.
That should
On Apr 9, 2009, at 2:20 PM, Jonathan Pryor wrote:
> On Thu, 2009-04-09 at 12:56 -0700, Casey Marshall wrote:
>> 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
On Thu, 2009-04-09 at 15:19 -0700, Casey Marshall wrote:
> On Apr 9, 2009, at 2:20 PM, Jonathan Pryor wrote:
> > It sounds like mdoc needs to support a -r:ASSEMBLY argument (or
> > -lib:PATH), to reference assemblies (for later lookup) but NOT
> > document them, thus assisting these cross-assembl
12 matches
Mail list logo
