ndoc-devel — Discussions about NDoc development

[ndoc-devel] Ndoc for 2005

[Strickland,David <dst...@mn...>]

I have a buildable 2005 copy based off of 1.3v13. I spent the better part of
the day today doing a simple port and reworking the Solution and project
classes to support the new formats. Is there another project everyone has
moved to already if not anyone got a suggestion where I can post this thing
so we can start testing/hacking on it. Granted it's got more bugs then a new
york slum and is probably about as Stable a democracy in Iraq but if no one
else has anything it'll be a place to start. If needed we could always
branch into a new SourceForge Project but that might be overkill and in the
end do more harm to the community then good.

Anyone care to comment?

The information contained in this message is confidential, protected from disclosure and may be legally privileged.  If the reader of this message is not the intended recipient or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any disclosure, distribution, copying, or any action taken or action omitted in reliance on it, is strictly prohibited and may be unlawful.  If you have received this communication in error, please notify us immediately by replying to this message and destroy the material in its entirety, whether in electronic or hard copy format.  Thank you.

RE: [ndoc-devel] How to create XSLT file with similar ability to SeeAlso

[Heath S. <clu...@ho...>]

If I might make one suggestion: be sure to include mailto: as the protocol =
in your href. If you were planning on just doing that in the transform cons=
ider that some organizations don't give out email addresses but URLs to onl=
ine contact forms. Specifying the protocol such as http: or mailto: in the =
XML documentation allows you maximum flexibility. And in case you're not fa=
miliar with HTML, not including mailto: before an email address in an A.hre=
f attribute will cause the browser to treat the email address as a relative=
 URL.


From: mi...@so...To: ndo...@li...Subject: [ndo=
c-devel] How to create XSLT file with similar ability to SeeAlsoDate: Tue, =
7 Feb 2006 10:52:21 +0000


Hi, i want to create a <contact> tag, and have it display in a similar fash=
ion to the <seealso> tag, ie:
=20
Contacts:
=20
Bob | Fred | Sam
=20
or
=20
Contacts:
=20
Bob
=20
etc
=20
To achieve this, i want to be able to do the following in my projects:
=20
/// <summary></summary>
/// <contact href=3D"ab...@xy...">Bob</contact>
/// <contact href=3D"xy...@ab...">Fred</contact>
public void MyFunc()
{
}
=20
=20
=20
Can anyone give me any help / tips on how to do this? I've looked at the co=
mmon.xslt file, and tried all sorts of variants, but i just cant get it to =
work.
=20
=20
=20
=20
Thanks
=20
Mark
=20
Mark IngramSoftware Engineer







Web:
www.softease.com


Tel:
01335 343421


Fax:
01335 343422


Email:
mi...@so...


Mail:
SofteaseMarket PlaceAshbourneDerbyshire DE6 1ES









This message is confidential. You should not copy it or disclose its conten=
ts to anyone. You may use and apply the information only for the intended p=
urpose. Internet communications are not secure and therefore Softease does =
not accept legal responsibility for the content of this message. Any views =
or opinions presented are only those of the author and not those of Softeas=
e. If the e-mail has come to you in error please delete it and any attachme=
nts. Please note that Softease may intercept incoming and outgoing e-mail c=
ommunications.
=20
=20
 =

RE: [ndoc-devel] How to create XSLT file with similar ability to SeeAlso

[Mark I. <mi...@so...>]

Sorry, that was just a typo, you're right, it should have the mailto:
infront of the email addresses.
=20
Thanks,
=20
Mark

________________________________

From: Heath Stewart [mailto:clu...@ho...]=20
Sent: 07 February 2006 17:20
To: Mark Ingram; ndo...@li...
Subject: RE: [ndoc-devel] How to create XSLT file with similar ability
to SeeAlso


If I might make one suggestion: be sure to include mailto: as the
protocol in your href. If you were planning on just doing that in the
transform consider that some organizations don't give out email
addresses but URLs to online contact forms. Specifying the protocol such
as http: or mailto: in the XML documentation allows you maximum
flexibility. And in case you're not familiar with HTML, not including
mailto: before an email address in an A.href attribute will cause the
browser to treat the email address as a relative URL.



________________________________

	From: mi...@so...
	To: ndo...@li...
	Subject: [ndoc-devel] How to create XSLT file with similar
ability to SeeAlso
	Date: Tue, 7 Feb 2006 10:52:21 +0000
=09
=09
=09
	Hi, i want to create a <contact> tag, and have it display in a
similar fashion to the <seealso> tag, ie:
	=20
	Contacts:
	=20
	Bob | Fred | Sam
	=20
	or
	=20
	Contacts:
	=20
	Bob
	=20
	etc
	=20
	To achieve this, i want to be able to do the following in my
projects:
	=20
	/// <summary></summary>
	/// <contact href=3D"ab...@xy...">Bob</contact>
	/// <contact href=3D"xy...@ab...">Fred</contact>
	public void MyFunc()
	{
	}
	=20
	=20
	=20
	Can anyone give me any help / tips on how to do this? I've
looked at the common.xslt file, and tried all sorts of variants, but i
just cant get it to work.
	=20
	=20
	=20
	=20
	Thanks
	=20
	Mark
	=20
=09
=09
	Mark Ingram
	Software Engineer
=09
=09
=09
 <http://www.softease.com/images/logo.gif> =09
Web:
www.softease.com <http://www.softease.com/> =09
Tel:
01335 343421=09
Fax:
01335 343422=09
Email:
mi...@so... <mailto:mi...@so...> =09
Mail:
Softease
Market Place
Ashbourne
Derbyshire=20
DE6 1ES=09
=09
________________________________

 <http://www.softease.com/images/logo.jpg> 	This message is
confidential. You should not copy it or disclose its contents to anyone.
You may use and apply the information only for the intended purpose.
Internet communications are not secure and therefore Softease does not
accept legal responsibility for the content of this message. Any views
or opinions presented are only those of the author and not those of
Softease. If the e-mail has come to you in error please delete it and
any attachments. Please note that Softease may intercept incoming and
outgoing e-mail communications.
	=20
	=20
	=20

Re: [ndoc-devel] Custom documentation topics with NDoc and MsdnDocumenter

[Atanas I. <ata...@gm...>]

First of all, many thanks for the comoprehensive reply :)

I agree with your point, but if I understood it correctly, it assumes that
the custom topics are already present in a ready-to-read form (html) - the
problem I'm trying to solve is in the previous stage of the documentation
process.

The reason for the decision to use NDoc for something like this, is the ide=
a
that we should apply for the custom topics the same principle which lies
behind C# xml comments:

DEVELOPMENT->ARTIFACTS->TRANSFORM->USABLE OUTPUT

where artifacts are par ex. code and docs - both in a well-defined, but
"raw" format like c# for the first and xml for the latter. In step #3, code
is transformed by the compiler and docs by tools like NDoc.

It seems logical to create custom topics in xml and then transform them
(with xslt) to html, so they can be merged with the code-related content.
However, XML docs->xslt->html is exactly what NDoc does...

So, if we want to start with xml and end with html which is in the
same style as
the code comment pages, all the xslt files should be copied from the NDoc's
sources and used by another tool which will contain the same logic as NDoc
(because it will have to perform the same transform of xml into html). This
was the first approach used (which I personally tried). However, I decided
to abandon it, because I didn't like the idea to write a tool which has as
functionality a subset of something already existing.

The "upgrade" to NDoc costed (yes, it is already completed) less than 2
days of the time of a single developer, which in all cases is less than the
effort which would be needed for the creation of a custom tool with the
capabilities required.

I consider NDoc and the different help compilers (and formats) as pieces
which from most of the puzzle named "automated documentation process", but
have the feeling that something is still missing. Maybe a solution with a
freely extensible and customizable transform pipeline which would be able
to handle virtually any kind of (xml) input and produce any kind of
documentation?

Best Regards,
Atanas Ilchev


2005/12/29, Heath Stewart <clu...@ho...>:
>
>  You don't need NDoc to do this job. If you're compiling CHMs you can
> decompile them using the HTML Help Workshop available from
> msdn.microsoft.com (this can even be automated) change the TOC (it's an
> HTML file - maybe even well-formed enough to be XML...I don't remember of=
f
> hand) and add in your other HTML pieces. If you're using the Msdn2
> documentor you can create your own HxS and HxI files and integrate them p=
er
> instructions for HTML Help2. The Visual Studio Combined Collection, for
> example, merges many TOCs and content files for VS itself, and the MSDN
> Library merge itself into the VSCC. Third parties can also do this.
>
> HTML Help (CHM) can do this with the proper application. Old MSDN Library
> used to do this.
>
> My point is don't make NDoc do something for which it's not intended when
> ways of doing this already exist. The tools exist and can be called via
> automation (like a batch script) to do what you need. This also allows yo=
u
> to decouple your other, non-API documentation from your API documentation
> which will, of course, change over time (though your other content may
> not...at least as much).
>
> My recommendation is to use HTML Help 2 if you can. Currently this does
> require either the .NET Framework SDK 1.0+, VS 7.0+, or recent (i.e., the
> last several years) MSDN Library (a couple other apps may come with
> it...don't remember off hand) but if you're developing a third-party cont=
rol
> for VS or .NET it's likely you can depend on Document Explorer being ther=
e.
>
> Sorry, but I'm not aware of any plans to yet release Document Explorer as
> a third-party redist (like HTML Help 1.x).
>
> ---
> *Heath Stewart
> *Software Design Engineer
> Developer Division Customer Product-Lifecycle Experience
> Microsoft Corporation
> http://blogs.msdn.com/heaths
>
> ------------------------------
> From: *Atanas Ilchev <ata...@gm...>*
> To: *ndo...@li...*
> Subject: *[ndoc-devel] Custom documentation topics with NDoc and
> MsdnDocumenter*
> Date: *Thu, 29 Dec 2005 15:03:34 +0200*
>
> Hi All,
>
> I'm responsible for a small team, which works on another open source
> project (http://sourceforge.net/projects/cybercore). However, as we all
> know, the whole effort is of a little value without a proper
> documentation...
>
> When it comes to documentation, NDoc is the tool which will play the
> central role (no surprises here). The problem is that currently NDoc can =
be
> used for only what I call "API refernce", which is far away from what I
> consider to be the necessary minimum.
>
> So I've assigned to one of the developers the task to "upgrade" the msdn
> documenter in such a way, which will permit us to create custom topic tre=
es
> in the TOC - they will lead to not-directly-code-related info (but with
> possible liks to the API reference). Here is the place to say, that she
> started to show some quite serious pregress...
>
> Regarding all this, I would like to ask 2 questions:
> - Is there something like this already realized? I do not like the
> possibility to come out with a re-invented wheel at the end...
> - Because this "enchancement" seems like a very serious candidate for
> contribution, is there such planned feature (i.e. - is there a need for
> such a contribution)?
>
>

RE: [ndoc-devel] Custom documentation topics with NDoc and MsdnDocumenter

[Heath S. <clu...@ho...>]

<html><div style='background-color:'><P>You don't need NDoc to do this job. If you're compiling CHMs you can decompile them using the HTML Help Workshop available from msdn.microsoft.com (this can even be automated) change the TOC (it's an HTML file - maybe even well-formed enough to be XML...I don't remember off hand) and add in your other HTML pieces. If you're using the Msdn2 documentor you can create your own HxS and HxI files and integrate them per instructions for HTML Help2. The Visual Studio Combined Collection, for example, merges many TOCs and content files for VS itself, and the MSDN Library merge itself into the VSCC. Third parties can also do this.</P>
<P>HTML Help (CHM) can do this with the proper application. Old MSDN Library used to do this.</P>
<P>My point is don't make NDoc do something for which it's not intended when ways of doing this already exist. The tools exist and can be called via automation (like a batch script) to do what you need. This also allows you to decouple your other, non-API documentation from your API documentation which will, of course, change over time (though your other content may not...at least as much).</P>
<P>My recommendation is to use HTML Help 2 if you can. Currently this does require either the .NET Framework SDK 1.0+, VS 7.0+, or recent (i.e., the last several years) MSDN Library (a couple other apps may come with it...don't remember off hand) but if you're developing a third-party control for VS or .NET it's likely you can depend on Document Explorer being there.</P>
<P>Sorry, but I'm not aware of any plans to yet release Document Explorer as a third-party redist (like HTML Help 1.x).</P>
<P>---<BR><STRONG>Heath Stewart<BR></STRONG>Software Design Engineer<BR>Developer Division Customer Product-Lifecycle Experience<BR>Microsoft Corporation<BR><A href="http://blogs.msdn.com/heaths">http://blogs.msdn.com/heaths</A></P>
<BLOCKQUOTE style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #a0c6e5 2px solid; MARGIN-RIGHT: 0px"><FONT style="FONT-SIZE: 11px; FONT-FAMILY: tahoma,sans-serif">
<HR color=#a0c6e5 SIZE=1>
From: <I>Atanas Ilchev &lt;ata...@gm...&gt;</I><BR>To: <I>ndo...@li...</I><BR>Subject: <I>[ndoc-devel] Custom documentation topics with NDoc and MsdnDocumenter</I><BR>Date: <I>Thu, 29 Dec 2005 15:03:34 +0200</I><BR><BR>
<DIV>Hi All,</DIV>
<DIV>&nbsp;</DIV>
<DIV>I'm responsible for a small team, which works on another open source project (<A href="http://sourceforge.net/projects/cybercore">http://sourceforge.net/projects/cybercore</A>).&nbsp;However, as we all know, the whole effort is of a little value without a proper documentation... </DIV>
<DIV>&nbsp;</DIV>
<DIV>When it comes to&nbsp;documentation,&nbsp;NDoc is the tool which will play the central role (no surprises here). The problem is that currently NDoc can be used for only what I call "API refernce", which is far away from what&nbsp;I consider&nbsp;to&nbsp;be the&nbsp;necessary minimum. </DIV>
<DIV>&nbsp;</DIV>
<DIV>So I've assigned to one of the developers the task to "upgrade" the msdn documenter in such a way, which will permit us&nbsp;to&nbsp;create&nbsp;custom topic trees in the TOC - they&nbsp;will lead to not-directly-code-related info&nbsp;(but&nbsp;with possible liks to the API reference).&nbsp;Here is the place to say, that&nbsp;she started to show some quite serious pregress... </DIV>
<DIV>&nbsp;</DIV>
<DIV>Regarding all this, I would like to ask 2 questions:</DIV>
<DIV>- Is there something like this already realized? I do not like the possibility to come out with a re-invented wheel at the end...</DIV>
<DIV>- Because this "enchancement"&nbsp;seems like a&nbsp;very serious candidate for contribution, is there such planned&nbsp;feature (i.e. - is there a need for such a contribution)?</DIV><BR></FONT></BLOCKQUOTE></div></html>

[ndoc-devel] Custom documentation topics with NDoc and MsdnDocumenter

[Atanas I. <ata...@gm...>]

Hi All,

I'm responsible for a small team, which works on another open source projec=
t
(http://sourceforge.net/projects/cybercore). However, as we all know, the
whole effort is of a little value without a proper documentation...

When it comes to documentation, NDoc is the tool which will play the centra=
l
role (no surprises here). The problem is that currently NDoc can be used fo=
r
only what I call "API refernce", which is far away from what I
consider to be the necessary minimum.

So I've assigned to one of the developers the task to "upgrade" the msdn
documenter in such a way, which will permit us to create custom topic trees
in the TOC - they will lead to not-directly-code-related info (but with
possible liks to the API reference). Here is the place to say, that she
started to show some quite serious pregress...

Regarding all this, I would like to ask 2 questions:
- Is there something like this already realized? I do not like the
possibility to come out with a re-invented wheel at the end...
- Because this "enchancement" seems like a very serious candidate for
contribution, is there such planned feature (i.e. - is there a need for suc=
h
a contribution)?

[ndoc-devel] ndoc support for dotnet 2.0

[Paul W. <pw...@lo...>]

Hi,

=20

What is the status of support for dotnet 2.0 in NDoc?  Is there a todo
list?  I'm willing to contribute time to the project to get support for
2.0 going.

=20

Thanks

~ Paul

[ndoc-devel] NDoc Wiki is Back Up

[Jason D. <ja...@in...>]

I just noticed on this weblog post that the NDoc wiki was down:

http://www.tkachenko.com/blog/archives/000533.html

SourceForge apparently changed things so that the user the web server
runs under can't write to the project directories. So I had to move
the data files from the ndoc project directory (under
/home/groups/n/nd/ndoc) to an area the web server user can write to:
/tmp/persistent/ndoc.

I'm a little worried about the "/tmp" prefix in that path. I'm hoping
it gets cancelled out by the "/persistent" part and that it actually
persists.

I'm sorry I have so little time and can no longer contribute to NDoc.
Any way we can recruit more developers now that 2.0 is out and final?

--
Jason

[ndoc-devel] Re: Any *nix web experts out there?

[Ainsworth, S. <Sco...@co...>]

Kevin,
=20
It has been a while, but I have run small web sites under
Linux/Apache/Perl and some PHP.  So I can probably help, but would like
to know what products I need skills in before I make a commitment.  My
biggest concern is my limited experience ensuring cross-browser
compatibily. =20
=20
I am very greatfull for you work and commitment to NDoc.  Please let me
know if I may be of service.
=20
Sincerely,
Scott Ainsworth

[ndoc-devel] Any *nix web experts out there?

[Kevin D. <kd...@op...>]

Hi everyone,

Are there any *nix web experts out there (especially with SourceForge
experience) that could give me a hand? 

My unix skills are old and generally suck, and I need some help
fixing/upgrading the NDoc site. I could probably do it myself, but I'm sure
people would rather I concentrate on the .Net 2.0 version of NDoc, rather
than wasting weeks on the web site :-)


Regards,
Kevin

[ndoc-devel] NDoc with mono-2.0 and linux

[Fabian <fa...@fs...>]

I managed to compile NDoc with both mono-1.0 and mono-2.0 under linux
with some minor changes. 

The things i've fixed are: 
Mono complains if the property warnaserror is set to true in the task
csc and ends with a build error. Misteriously it compiles ok if it is
set to false. This is true for both mono-1.0 and mono-2.0. 

The other fix was to include references to System.DirectoryServices.

I'm quite newbie so don't know if some thing could be better achived by
other way. 

I'll attach my patch so it can be reviewed. 

-- 
gpg --keyserver pgp.rediris.es --recv-keys F6FEF105

[ndoc-devel] NDoc for .Net 2.0 beta 2 - early testers required

[Kevin D. <kd...@op...>]

Greetings everyone,

I now have a "sneak preview" version of NDoc for .Net 2.0 beta 2 up and
running...

It is a very 'experimental' build, there is still much to do before it even
gets to beta quality, but I am looking for some brave testers to start
playing with it :-)

I am especially interested in anyone building large projects as I have put a
lot of work into performance improvements and I'd like to get a feel for how
much difference they will make in 'real world' scenarios. 

Anyone wishing to volunteer their services should contact me off-list at
kd...@us...

---
Kevin

"Whatever it is, I fear Geeks even when they bring gifts." - after Virgil
 

RE: [ndoc-devel] (no subject)

[Kral F. <kra...@ho...>]

Adam,

Do you know the format of the MIF or MML document?  If you have a 
specification for that then you may want to convert the information that 
NDoc provides (extracted code comments and reflection of the type 
information) into the native Framemaker format.  If you are talking about 
relying on something in the middle like first targeting Javadoc, HTML, or La 
TeX then you'd need to make sure that those NDoc targets have code that is 
up to date.  It's really your choice and it's about reading the code of NDoc 
to see what would best fit what you are trying to do...

Kral

>From: Adam Robey <A....@md...>
>To: "NDoc Developers List (ndo...@li...)" 
><ndo...@li...>
>Subject: [ndoc-devel] (no subject)
>Date: Mon, 2 May 2005 11:08:50 -0700
>
>Hello again. I posted this query back in December (of last year), but no 
>one
>seemed to have any ideas then. So, I'm posting it one more time...
>
>I'm exploring ways of putting NDoc output into FrameMaker files. I've
>considered the following options thus far:
>*	Write my own documenter that creates MIF files (or MML files). I've
>been studying the Javadoc MIF doclet for insights on the best way to
>implement this. (I've written Javadoc doclets before, but I've never 
>written
>an NDoc documenter.)
>*	Use the LaTeX documenter to generate LaTeX files, and then convert
>the LaTeX files to MIF files (or MML files). However, I've only found one
>LaTeX-to-MIF converter thus far. It's for the Unix platform, we mainly use
>PCs.
>*	Use one of the HTML documenters to generate HTML files, and then
>convert the HTML files to MIF files (or MML files). There are several
>HTML-to-MIF converters out there.
>
>Has anyone tried any of these ideas? Does anyone have any other 
>suggestions?
>
>Thanks very much for any information.
>
>-Adam Robey
>

[ndoc-devel] (no subject)

[Adam R. <A....@md...>]

Hello again. I posted this query back in December (of last year), but no one
seemed to have any ideas then. So, I'm posting it one more time...

I'm exploring ways of putting NDoc output into FrameMaker files. I've
considered the following options thus far:
*	Write my own documenter that creates MIF files (or MML files). I've
been studying the Javadoc MIF doclet for insights on the best way to
implement this. (I've written Javadoc doclets before, but I've never written
an NDoc documenter.)
*	Use the LaTeX documenter to generate LaTeX files, and then convert
the LaTeX files to MIF files (or MML files). However, I've only found one
LaTeX-to-MIF converter thus far. It's for the Unix platform, we mainly use
PCs.
*	Use one of the HTML documenters to generate HTML files, and then
convert the HTML files to MIF files (or MML files). There are several
HTML-to-MIF converters out there.

Has anyone tried any of these ideas? Does anyone have any other suggestions?

Thanks very much for any information.

-Adam Robey

[ndoc-devel] Developping NDoc...

[TheProof <The...@gm...>]

Hey ! I=92am very impressed of you actual work. And that is he reason =
why i do
like to become a member of the developping team.

=20

Yes, I WOULD LIKE TO BECOME A MEMBER IN YOUR DEVELOPING TEAM OF NDoc

=20

I come from Austria, but english isn=92t really a problem for me , so i =
hope
for a positiv anser from the admin to my adress.

[ndoc-devel] Including source within the documentation

[hammett <ha...@gm...>]

Hi there,=20

First of all, you have a great product. keep up the good work.

I wonder whether would be possible to include the source within the
documentation as Ruby docs do. Check this:

http://api.rubyonrails.com/classes/ActionController/Caching/Pages/ClassMeth=
ods.html

See the "show source"

Would that be possible through a plug in?

--=20
Cheers,
hammett
http://www.castleproject.org/~hammett

RE: [ndoc-devel] MSDN Documentation Type and namespace hierarchies

[Kevin D. <kd...@op...>]

Martin,
 
From memory, it should be possible to do this with the msdn documenter in
the current 'development' source; I thing the setting was 'TocStyle'...
 
Note that this is not a fully tested feature, and is only available on the
MSDN documenter. I am currently investigating this feature and will be
adding it to the next major version. Until that time, your mileage may vary
:)
 
Kevin
 


  _____  

From: ndo...@li...
[mailto:ndo...@li...] On Behalf Of Martin Welch
Sent: Saturday, 16 April 2005 8:33 PM
To: ndo...@li...
Subject: [ndoc-devel] MSDN Documentation Type and namespace hierarchies



Hi, 

Assuming I have the following namespaces: 

Product.Module 
Product.Module.Controls 
Product.Module.Views 
Product.Module.Wizards 

Using the MSDN documentation type I get the same list in the resulting help
(with the little purple book beside each namespace). Using ASCII art it's
something like the following (where X is the purple book icon):

X Product.Module 
   X SomeClass Class 
X Product.Module.Controls 
   X SomeCtrl Class 
X Product.Module.Views 
   X SomeView Class 
X Product.Module.Wizards 
   X SomeWizard Class 

Is it possible to get NDOC to indent the namespaces with each 'child'
namepace getting its own book icon? e.g: 

X Product.Module 
   X Product.Module.Controls 
      X SomeCtrl Class 
   X Product.Module.Views 
      X SomeView Class 
   X Product.Module.Wizards 
      X SomeWizard Class 
   X SomeClass Class 

Thanks, 

Martin 

[ndoc-devel] MSDN Documentation Type and namespace hierarchies

[Martin W. <mar...@il...>]

Hi,

Assuming I have the following namespaces:

Product.Module
Product.Module.Controls
Product.Module.Views
Product.Module.Wizards

Using the MSDN documentation type I get the same list in the resulting
help (with the little purple book beside each namespace). Using ASCII
art it's something like the following (where X is the purple book icon):

X Product.Module
   X SomeClass Class
X Product.Module.Controls
   X SomeCtrl Class
X Product.Module.Views
   X SomeView Class
X Product.Module.Wizards
   X SomeWizard Class

Is it possible to get NDOC to indent the namespaces with each 'child'
namepace getting its own book icon? e.g:

X Product.Module
   X Product.Module.Controls
      X SomeCtrl Class
   X Product.Module.Views
      X SomeView Class
   X Product.Module.Wizards
      X SomeWizard Class
   X SomeClass Class

Thanks,

Martin

[ndoc-devel] I18N

[Koji M. <km...@t3...>]

Hi all,

In Japan, We have the localized NDoc 1.3.1 (NDoc 1.3.1 Japanese Edition).
(See http://sourceforge.jp/projects/ndoc-jp/ )
We add some changes about internationalization in localizing.
I regards these changes as effective also to other languages.
I will be glad if these change is merged.

The change which we made is as follows.
1. Localized XSLT resources
   We add some localized xlst resources (*.ja.xslt).
   (VS.NET make a satellite assembly automatically.)
2. Strings resources
   We separate some hardcoding strings into resources. (Strings.resx)
   (VS.NET make a satellite assembly automatically.)
3. Changing code
   "kmatsu" is described in the part which I changed.
   Please search the keyword "kmatsu".

Please download from the following:
http://prdownloads.sourceforge.jp/ndoc-jp/13667/ndoc-ja-devel-v1.3.1-rev0.zip

[ndoc-devel] we's famous

[Donald K. <dka...@ya...>]

http://msdn.microsoft.com/vbasic/default.aspx?pull=/library/en-us/dv_vstecha
rt/html/VBGeneratingDocs.asp

[ndoc-devel] [ANN] NDocContrib

[Donald K. <dka...@ya...>]

Since users are now implementing their own tags via NDoc's extensibility
feature, we thought it would be a good idea to make it easier for people to
share their work with one another.

 

To that end, we have put together the NDocContrib program so that tags and
custom templates can be shared and re-used amongst NDoc users.

 

User contributions will be made available on the NDoc website, and as part
of the NDoc installer.

 

Submitting your contribution is simply a matter of sending a ZIP file to
NDo...@gm.... Your submission should include:

* Your name and SourceForge login name 

* A short description of your tag or template 

* A ZIP file containing the following: 

o        The XSLT implementation of your tag 

o        Buildable example C# code (preferably within a VS.NET project) 

o        An NDoc project that documents your example assembly; using your
stylesheet 

o        An optional readme file that explains the history, usage and
implementation of the tag or template 

 

Details and an example submission are available at:
http://ndoc.sourceforge.net/content/contrib.htm.

 

In addition, in order to get things started, we are giving away a free
SourceForge.net t-shirt to the first five entries.

 

So share your custom tags and get a free t-shirt while they last!

 

Cheers,

 

Don Kackman

[ndoc-devel] ndoc contrib

[Donald K. <dka...@ya...>]

So I've set up some simple infrastructure for supporting user systelsheet
contribs.

 

I had set up a list.sf.net box for accepting contributions, but sourceforge
is still blocking zip files on their lists so I've gone with a gmail
account: NDo...@gm.... If you are interested in moderating
contributions let me know and I'll send you the password for the account.

 

Please take a look at http://ndoc.sourceforge.net/content/contrib.htm and
let me know what you think.

 

If anybody's got some tag templates to help start things off let me know so
that I can get em included before posting announcements to ndoc-users etc.

 

Also, I'm going to give away t-shirts to the first 5 contributors to try and
get things going - sorry devs aren't eligible ;-)

 

http://www.thinkgeek.com/interests/ostg/71ad/

 

Cheers,

 

don

Re: [ndoc-devel] Sharing custom tags

[<joh...@co...>]

This sounds like a good solution.
It would also help reduce duplicate functionality.
  ----- Original Message -----=20
  From: Donald Kackman=20
  To: ndo...@li...=20
  Sent: Friday, January 28, 2005 8:24 PM
  Subject: [ndoc-devel] Sharing custom tags


  Since a number of people are starting to implement their own tags via =
the extensibility mechanism, it would be nice if we could all share =
their implementations.

  =20

  For this reason I'd like to propose the following mechanism for =
facilitate the sharing user contributions:

  =20

  Submission

  Contribution would come in the form of an email to one of the admins =
or volunteers from among the active devs (or if there are more active =
contributors, they can become devs themselves). Much like a contribution =
to codeproject, the email should contain the submitter's full name, a =
short description of the tag or template, and a ZIP file containing the =
following:

    a.. An extensibility stylesheet(s) implementing the tag (including =
the submitter's license of choice)=20
    b.. A build-able example, including code, preferably within a VS.NET =
project=20
    c.. An NDoc project that documents the example assembly=20
    d.. An optional readme file that explains the history, usage and =
implementation of the tag=20
  =20

  Validation

  Whoever receives the submission would do a quick smoke test on the =
example project, ensuring that the submission works as advertised. If =
the submission works, it gets committed to CVS (see storage) and one of =
the admins is notified so the web site can be updated (see access). If =
not Whoever received the submission can work with the submitter to =
correct any problems.

  =20

  Storage

  We create a directory structure in CVS for storage of the ZIP files

  ndoc

              \contrib

                          \tags

                          \templates

  =20

  Access

  We'll add a new page to ndoc.sf.net that catalogs the available =
contributions and allows for download of the ZIP file. We can also =
distribute them with the installer and the nightly tar-ball.

  =20

  Let me know if this all sounds good or if there is anything I'm not =
thinking of.

  =20

  don

RE: [ndoc-devel] about my latest CVS commit

[Donald K. <dka...@ya...>]

PS It is now the IDocumenterInfo type that gets searched for when looking
for available documenters (refer to the class InstalledDocumenters.cs for
details).

 

When creating new documenters it will be necessary to create an
implementation of IDocumenter, IDocumenterConfig and IDocumenterInfo.

 

don

 

  _____  

From: ndo...@li...
[mailto:ndo...@li...] On Behalf Of Donald Kackman
Sent: Saturday, January 29, 2005 7:29 PM
To: ndo...@li...
Subject: [ndoc-devel] about my latest CVS commit

 

In preparation for using an unloadable AppDomain to do the documentation
build, rather than a thread, I've reversed the relationship between
IDocumenter and IDocumenterConfig. 

 

Up until now, as soon as the GUI was loaded all of the IDocumenters were
also loaded, and A LOT of the memory that each consumed as builds were done,
was not released.

 

Now only the much less memory intensive IDocumenterConfig classes (and a new
IDocumenterInfo helper type) are loaded by the GUI and when a build is done,
the IDocumenter is created and then discarded. This should result in some
immediate memory gains, as the documenter will now be eligible for garbage
collection after the build is complete, rather than hanging around, attached
to the UI.

 

The next step is to create the IDocumenter in a separate AppDomain so that
it can be unloaded completely, along with the assemblies that are being
documented.

 

In the meantime, please let me know of any bugs or unexpected errors that
you notice in the dev branch. There were a lot of different places that I
touched for this change and even though I'm pretty sure I got it pretty well
debugged, you never know.

 

Cheers,

 

don

[ndoc-devel] about my latest CVS commit

[Donald K. <dka...@ya...>]

In preparation for using an unloadable AppDomain to do the documentation
build, rather than a thread, I've reversed the relationship between
IDocumenter and IDocumenterConfig. 

 

Up until now, as soon as the GUI was loaded all of the IDocumenters were
also loaded, and A LOT of the memory that each consumed as builds were done,
was not released.

 

Now only the much less memory intensive IDocumenterConfig classes (and a new
IDocumenterInfo helper type) are loaded by the GUI and when a build is done,
the IDocumenter is created and then discarded. This should result in some
immediate memory gains, as the documenter will now be eligible for garbage
collection after the build is complete, rather than hanging around, attached
to the UI.

 

The next step is to create the IDocumenter in a separate AppDomain so that
it can be unloaded completely, along with the assemblies that are being
documented.

 

In the meantime, please let me know of any bugs or unexpected errors that
you notice in the dev branch. There were a lot of different places that I
touched for this change and even though I'm pretty sure I got it pretty well
debugged, you never know.

 

Cheers,

 

don