Rick LaPlante's WebLog

How does the framework's MSDN docs produced? <br>If you could supply a tool that produces documentation the same format as the MSDN docs that'll be great...

Is it possible to use a custom build step to execute an external command such as NDoc, which I believe has a command line version? <br> <br>If you can trigger third-party command-line processes from the build process, there is no need for MS to duplicate a great utility like NDoc. <br> <br>BTW: NDoc takes takes the XML comments that C# can extract from the source and make a nice looking documentation file in chm and other formats.

I actually helped with NDoc 1.2 in getting an Help2 documenter reader, though I was disappointed hearing that Help2 would no longer be supported (though that turned out to be, in part, untrue; now we have Help2.1). <br> <br>The whole time I helped a little with the MSDN documenter and helped work on the Help2 documenter, I was thinking it would be nice to have something like Microsoft uses (at the time I didn't work here). After all, most of the NDoc devs were busy trying to replicate the look and feel of the Microsoft docs for consistency. <br> <br>Why not something similar - if not the same thing - that Microsoft uses internally? Perhaps even integration with Microsoft CMS would create synergy for ISVs.

Excerpt: How is MS blind to what vocal people are doing with their tools?

The scenario you should support is providing the NDOC step in the default build process. The only thing that needs to be done is provide a MS build task that gives NDOC the appropriate commandline information to run. From that, the tool will generate the documentation as you would like. So it should be very simple to implement. Adding this as an additional step to Bigbuild is also very easy to do. (i know this because we already did here at Info Support:-)) You would back up the documentation creation as well by providing an additional check in policy that checks if you have xml documentastion enabled in your project before you check in. <br>b.t.w. don't try to implement the NDOC task the same way as done in NANT because that task is broken badly! they use the inner workings of NDOC in stead of just calling the commandline utility and this implementation results in broken documents very often while using commandline works just fine. If you like I would be more than hapy to help with this scenario because it's already on our schedule for the TAP project after we get the B2 bits.

If Team System is going to be an end to end solution, there are a lot of areas that need to be addressed. <br> <br>1. There has to be some form of Continuous Integration. Based on the latest MSDN mag, it appears that CI is handled through a build server, which will work. It did not, however, mention an automated build process linked to SourceControl, like CruiseControl.NET, etc. Since Source Control in Team System allows for shelving, a system that builds on actual &quot;check in&quot; would be nice. <br> <br>2. Documentation - nDoc is a nice tool, if you can get devs working with it. Being able to pull &quot;comments&quot; from source and create a set of documentation is invaluable for a high speed team. Is it a &quot;make it or break it&quot; part of Team System? I would say no.

I don't think it is necessary, but I'm just one person. <br> <br>When we want to release documentation at the API level, NDoc is invaluable! I believe this functionality is something that can be added with an extention to MSBuild just as Tasks are added to NAnt. <br> <br>So it isn't necessary to have it built into team system, just make it available with a task in MSBuild.

Shouldn't we look to the nDoc team to integrate with Team System?

I really wonder why didn' you check those very useful tools, anway, I like NDoc very much

nDoc is a wonderful tool, but this is one of those things where you have to ask, is it something you need built into the base IDE or is it better that a third party manages its development as a plug-in? <br> <br>I think in this case it's far more likely for a third-party to developer to be able to focus on making nDoc a great tool than to expect Microsoft to do this. <br> <br>I think this will be a recurring theme. There are many little things that make an IDE completely usable. Some of those things are and should be third-party plugins. <br> <br>My two cents. <br> <br>David C.